more specific route что это

Рекурсивная маршрутизация в MikroTik

Принцип работы рекурсивной маршрутизации в MikroTik и что такое scope и target-scope

Рекурсивная маршрутизация

Данная реализация поведения маршрутизации появилась из-за того, что в протоколе BGP при распространении маршрутов полученных через eBGP в iBGP next-hop по умолчанию, не меняется. Но не будем о BGP, а будем о простом.

Давайте начнём с простого, ниже я привёл таблицу маршрутизации простого маршрутизатора без каких либо излишек.

Смотря на таблицу маршрутизации выше, ответьте на вопрос. Какой шлюз будет выбран для отправки пакета на адрес 8.8.8.8?

Я более чем уверен, что вы абсолютно правильно определили шлюз как 10.11.100.254 в маршруте 0.0.0.0/0 по номером ноль.

А теперь попробуйте ответить на следующий вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8? Почувствуйте разницу, в первом вопросе я спрашивал про шлюз, а в данном вопросе про интерфейс.

И вы скорее всего все ответите, что ether1 и будете правы, но вопрос почему именно так.

Задача маршрутизатора, определить не шлюз, а интерфейс выхода, так как маршрутизатору надо будет понять как передать до шлюза пакет, если тип ethernet, то необходимо будет выяснить с помощью arp mac адрес шлюза, если это какой-то тип инкапсуляции, то пакет надо обернуть в данный тип инкапсуляции и отправить, на адрес пира.

Я не могу, вам показать fullview таблицу маршрутизации, так как она бы банально заняла огромное место на данной странице.

И так представьте у себя в голове таблицу маршрутизации в 700000 маршрутов. Представили?!

Я намеренно проигнорирую такие вещи как Кеш таблицы маршрутизации. (Представим, что его нет.)

Перед маршрутизатором стоит задача, отправить пакет на адрес 8.8.8.8

В данном процесс поиска, есть одно тонкое место, при повторном поиске маршрута, уже до адреса шлюза 5.5.5.1 маршрутизатор проходит опять всю таблицу маршрутизации. Вам не кажется, что это немного излишне? Строго говоря адрес шлюза должен быть в непосредственно присоединенной сети к маршрутизатору! Так может следующий поиск осуществлять только среди connected маршрутов? да это было бы идеально. Но так как я уже написал выше, в протоколе BGP при передачи маршрута из eBGP в iBGP адрес шлюза не меняется, то шлюз уже не может быть connected. И что же делать?

Scope

В linux, а так как RouterOS основан на Linux, то также и в RouterOS введено такое понятие как scope маршрута и target-scope

У любого маршрута есть, свой scope и target-scope.

Теперь давайте смотря на таблицу маршрутизации выше, попробуем ответить на вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8?

Значения Scope

Значение вы можете править руками, как для scope так и для target-scope. В случае с динамической маршрутизацией вы можете scope или target-scope указать с помощью фильтров маршрутизации, но вам необходимо знать, что есть предустановленные значения.

Все типы маршрутов, кроме на iBGP, основаны на состоянии интерфейса, ну возможно eBGP немного сбоку стоит, так как по умолчанию он требует прямой связности с пиром, хотя это обходится с помощью multihop. А iBGP у него target-scope = 30, так как адрес шлюза не меняется, и нужен ещё один какой-то протокол, который бы сообщил как достичь сети nexthop-a. Например статический маршрут или зачастую ospf.

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

И так давайте переделаем дефолтный маршрут, и адрес шлюза укажем не наш шлюза, а например 8.8.8.8

Создадим маршрут до 8.8.8.8 через шлюз нашего провайдера.

Создали, маршрут но маршрут по умолчанию, до сих пор не активен. Так как маршрутизатор всё также не смогу найти, маршрут до 8.8.8.8, так как target-scope дефолтного маршрута равен 10, и именно среди таких scope будет производится поиск до адреса 8.8.8.8. Нам необхоидимо установить scope маршрута 8.8.8.8, так чтобы он попадал под поиск, а это значит установить scope либо 10 или меньше. Сделаем.

И наблюдаем, то что поднялся рекурсивный маршрут. gateway-status=8.8.8.8 recursive via 10.11.100.254

Теперь давайте ещё раз ответим на вопрос, только изменим адрес назначения. Какой интерфейс будет выбран для отправки пакета на адрес 4.4.4.4?

А теперь мы можем сделать следующее, мы можем указать, использовать check-gateway и тем самым проверять доступность 8.8.8,8, и если будут недоступны, маршрут умрёт, и станет активным какой-нибудь другой маршрут с худшей дистанцией, например через LTE интерфейс.

Вы можете сделать рекурсивно, друг за другом, но это не имеет значение не в каких целях.

Одними 8.8.8.8 сыт не будешь

Да конечно, если упадёт 8.8.8.8, то мало не поздоровиться, будете переделывать. Можно поступить следующим образом.

Например взять три хоста высокой доступности 1.1.1.1, 8.8.8.8 и 77.88.8.8, можете любые свои, главное чтобы они действительно максимально всегда были доступны.

Создать три маршрута, через нашего провайдера. Таким образом

Далее создать три дефолтных рекурсивных маршрута, разной дистанцией.

В итоге, у вас будет такая картина в Winbox.

Если от 77.88.8.8 перестанет приходить ответы icmp, но при этом 8.8.8.8 будет приходить, то маршрут через шлюз 77.88.8.8 выпадет из процесса маршрутизации и его место займет следующий дефолтный маршрут по дистанции.

Часто слышу вопрос, а как сделать так, чтобы можно сделать через PPPoE рекурсивный маршрут? Тут всё дело в понимании, как таковой адрес шлюза не используется, кроме как в ethernet сетях, так как в ethernet нам нужен его mac адрес, в любых типах инкапсуляции в том числе и PPPoE адрес шлюза не используется, в виду того, что маршрутизатору просто надо запихнуть пакет в другой протокол и отправить на другую сторону.

Естественно мы можем этим воспользоваться.

Создайте отдельный PPP Profile и укажите абсолютно любой IP адрес в поле remote-address, главное чтобы этот адрес не пересекался с вашими внутренними сетями. Далее укажите этот профиль в настройках вашего PPPoE клиента, и вы можете использовать указанный адрес в поле remote-address, как адрес шлюза, для настройки рекурсивной маршрутизации.

Источник

Manual:IP/Route

Applies to RouterOS: v3, v4, v5+

Contents

Overview

Router keeps routing information in several separate spaces:

Routing Information Base

RIB (Routing Information Base) contains complete routing information, including static routes and policy routing rules configured by the user, routing information learned from routing protocols, information about connected networks. RIB is used to filter routing information, calculate best route for each destination prefix, build and update Forwarding Information Base and to distribute routes between different routing protocols.

By default forwarding decision is based only on the value of destination address. Each route has dst-address property, that specifies all destination addresses this route can be used for. If there are several routes that apply to a particular IP address, the most specific one (with largest netmask) is used. This operation (finding the most specific route that matches given address) is called routing table lookup.

If routing table contains several routes with the same dst-address, only one of them can be used to forward packets. This route is installed into FIB and marked as active.

When forwarding decision uses additional information, such as a source address of the packet, it is called policy routing. Policy routing is implemented as a list of policy routing rules, that select different routing table based on destination address, source address, source interface, and routing mark (can be changed by firewall mangle rules) of the packet.

All routes by default are kept in the main routing table. Routes can be assigned to specific routing table by setting their routing-mark property to the name of another routing table. Routing tables are referenced by their name, and are created automatically when they are referenced in the configuration.

Each routing table can have only one active route for each value of dst-address IP prefix.

There are different groups of routes, based on their origin and properties.

Default route

Route with dst-address 0.0.0.0/0 applies to every destination address. Such route is called the default route. If routing table contains an active default route, then routing table lookup in this table will never fail.

Connected routes

Connected routes are created automatically for each IP network that has at least one enabled interface attached to it (as specifie in the /ip address configuration). RIB tracks status of connected routes, but does not modify them. For each connected route there is one ip address item such that:

Multipath (ECMP) routes

Because results of the forwarding decision are cached, packets with the same source address, destination address, source interface, routing mark and ToS are sent to the same gateway. This means that ECMP route does not perform pure per-connection balancing, but it can be used to load balance connections if at least one of previously mentioned parameters is different than previous connection. See interface bonding if you need to achieve per-packet load balancing.

To implement some setups, such as load balancing, it might be necessary to use more than one path to given destination. However, it is not possible to have more than one active route to destination in a single routing table.

ECMP (Equal cost multi-path) routes have multiple gateway nexthop values. All reachable nexthops are copied to FIB and used in forwarding packets.

OSPF protocol can create ECMP routes. Such routes can also be created manually.

Routes with interface as a gateway

Value of gateway can be specified as an interface name instead of the nexthop IP address. Such route has following special properties:

Route selection

Each routing table can have one active route for each destination prefix. This route is installed into FIB. Active route is selected from all candidate routes with the same dst-address and routing-mark, that meet the criteria for becoming an active route. There can be multiple such routes from different routing protocols and from static configuration. Candidate route with the lowest distance becomes an active route. If there is more than one candidate route with the same distance, selection of active route is arbitrary (except for BGP routes).

BGP has the most complicated selection process (described in separate article). Notice that this protocol-internal selection is done only after BGP routes are installed in the main routing table; this means there can be one candidate route from each BGP peer. Also note that BGP routes from different BGP instances are compared by their distance, just like other routes.

Criteria for selecting candidate routes

To participate in route selection process, route has to meet following criteria:

Nexthop lookup

Nexthop lookup is a part of the route selection process.

Routes that are installed in the FIB need to have interface associated with each gateway address. Gateway address (nexthop) has to be directly reachable via this interface. Interface that should be used to send out packets to each gateway address is found by doing nexthop lookup.

Some routes (e.g. iBGP) may have gateway address that is several hops away from this router. To install such routes in the FIB, it is necessary to find the address of the directly reachable gateway (an immediate nexthop), that should be used to reach the gateway address of this route. Immediate nextop addresses are also found by doing nexthop lookup.

Nexthop lookup is done only in the main routing table, even for routes with different value of routing-mark. It is necessary to restrict set of routes that can be used to look up immediate nexthops. Nexthop values of RIP or OSPF routes, for example, are supposed to be directly reachable and should be looked up only using connected routes. This is achieved using scope and target-scope properties.

Recursive nexthop lookup example

Interface and immediate nexthop are selected based on the result of nexthop lookup:

Forwarding Information Base

FIB (Forwarding Information Base) contains copy of information that is necessary for packet forwarding:

By default (when no routing-mark values are used) all active routes are in the main table, and there is only one hidden implicit rule («catch all» rule) that uses the main table for all destination lookups.

Routing table lookup

FIB uses following information from packet to determine it’s destination:

Possible routing decisions are:

Results of routing decision are remembered in the routing cache. This is done to improve forwarding performance. When another packet with the same source address, destination address, source interface, routing mark and ToS is routed, cached results are used. This also allows to implement load balancing using ECMP routes, because values used to lookup entry in the routing cache are the same for all packets that belong to the same connection and go in the same direction.

If there is no routing cache entry for this packet, it is created by running routing decision:

Result of routing decision can be:

Rules that do not match current packet are ignored. If rule has action drop or unreachable, then it is returned as a result of the routing decision process. If action is lookup then destination address of the packet is looked up in routing table that is specified in the rule. If lookup fails (there is no route that matches destination address of packet), then FIB proceeds to the next rule. Otherwise:

Result of this routing decision is stored in new routing cache entry.

Properties

Route flags

General properties

Other Read-only properties

BGP Route Properties

These properties contain information that is used by BGP routing protocol. However, values of these properties can be set for any type of route, including static and connected. It can be done either manually (for static routes) or using route filters.

Источник

A more specific BGP route vs. a less specific static route, which is selected?

So in the following two routing table entries:

Which would be selected? I know that static routes are chosen over BGP (and other) routes, and more specific routing entries are chosen over less specific, however, which one takes precedence? I want to say the static route, however I’m just not sure.

2 Answers 2

A more specific route is what is used to forward packets. The two prefixes you have are really that, two separate prefixes, just as if they were in completely different network blocks. You are trying to compare apples to oranges

If, on the other hand, the the prefixes were equal length, the static route would be used (assuming default ADs are used).

In that case the answer would be : the more specific route will be selected, whatever the difference in administrative distances between the respective protocols.

Example : Router junos2 advertises 10.1.1.0/24 to router junos1.

Router junos1 has a static route to 10.1.0.0/16, discarding traffic to that less-specific prefix :

junos1 configuration

Router junos1 is receiving the more specific route from neighbour junos2 via BGP :

Checking the routing table, we see both routes are installed :

For addresses within prefix 10.1.1.0/24, the more specific, BGP-learned route is preferred (even with an AD of 170 against 5 for the static route) :

Источник

Основы статической маршрутизации в Mikrotik RouterOS

Маршрутизация — процесс поиска оптимального пути для передачи пакетов в сетях TCP/IP. Любой устройство подключенное к сети IPv4 содержит процесс и таблицы маршрутизации.

Данная статья не является HOWTO, она описывает на примерах статическую маршрутизацию в RouterOS, я намеренно опускал остальные настройки (например srcnat для доступа в сеть интернет), поэтому для понимания материала требуется определенный уровень знания по сетям и RouterOS.

Коммутация и маршрутизация

Маршрутизация — процесс передачи пакетов между Layer2 сегментами. Если устройство хочет отправить пакет, получатель которого находится за пределами Ethernet сегмента, оно смотрит в свою таблицу маршрутизации и передает пакет шлюзу, который знает куда отправить пакет дальше (а может и не знает, изначальный отправитель пакета про это не осведомлен).

Проще всего рассматривать маршрутизатор, как устройство подключенное к двум или более Layer2 сегментам и способное передавать пакеты между ними определяя оптимальный маршрут по таблице маршрутизации.

Если вам все понятно или вы и так это знали, то читайте дальше. Остальным настоятельно рекомендую ознакомиться с маленькой, но очень емкой статьей.

Маршрутизация в RouterOS и PacketFlow

Практически весь функционал относящийся к статической маршрутизации находится в пакете system. Пакет routing добавляет поддержку алгоритмов динамической маршрутизации (RIP, OSPF, BGP, MME), Routing Filters и BFD.

На PacketFlow можно выделить три места, где принимаются решения о маршрутизации IP пакетов:

RIB, FIB, Routing Cache

Routing Information Base
База в которой собираются маршруты от протоколов динамической маршрутизации, маршруты от ppp и dhcp, статические и подключенные (connected) маршруты. Данная база содержит все маршруты, за исключением отфильтрованных администратором.

Условно, можно считать что [IP]->[Route] отображает RIB.

Forwarding Information Base

База в которой собираются наилучшие маршруты из RIB. Все маршруты в FIB являются активными и используются для пересылки пакетов. Если маршрут становится неактивным (отключен администратором (системой), или интерфейс через который должен отправляться пакет не активен) маршрут удаляется из FIB.

Для принятия решения о маршрутизации в таблице FIB используются следующие данные о IP пакете:

Попадая в FIB пакет проходит следующие стадии:

Условно, можно считать что [IP]->[Route Active=yes] отображает FIB.

Routing Cache
Механизм кэширования маршрутов. Маршрутизатор запоминает куда были отправлены пакеты и если встречаются похожие (предположительно из одного соединения) пускает их по тому-же маршруту, без проверки в FIB. Кэш маршрутов периодически очищается.

Данный механизм был удален из ядра linux 3.6, но в RouterOS до сих пор используется kernel 3.3.5, возможно Routing cahce — одна из причин.

Диалог добавления маршрута

[IP]->[Route]->[+]

Флаги маршрутов

Что указывать в gateway: ip-адрес или интерфейс?

Система позволяет указывать и то, и другое, при этом не ругается и не дает подсказок, если вы что-то сделали неправильно.

IP адрес
Адрес шлюза должен быть доступен по Layer2. Для Ethernet это означает, что роутер должен иметь на одном из активных интерфейсов ip адрес из той же подсети, для ppp — что адрес gateway указан на одном из активных интерфейсов в качестве адреса подсети.
Если условие доступности по Layer2 не выполняется — маршрут считается неактивным и не попадает в FIB.

Интерфейс
Все сложнее и поведение маршрутизатора зависит от типа интерфейса:

Старайтесь указывать ip адрес в качестве gateway всегда когда это возможно. Исключение — connected маршруты (создаются автоматически) и PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) интерфейсы.

OpenVPN не содержит PPP заголовка, но можно использовать имя OpenVPN интерфейса для создания маршрута.

More Specific Route

Основное правило маршрутизации. Маршрут описывающий более маленькую подсеть (с наибольшей маской подсети) имеет больший приоритет при принятии решения о маршрутизации пакета. Положение записей в таблице маршрутизации не имеет отношения к выбору — основное правило More Specific.

Все маршруты из указанной схемы активны (находятся в FIB), т.к. указывают на различные подсети и не конфликтуют между собой.

Если один из шлюзов станет недоступным, связанный маршрут будет считаться неактивным (удален из FIB) и для пакетов будет производиться поиск из оставшихся маршрутов.

Маршруту с подсетью 0.0.0.0/0 иногда придают особое значение и называют «Маршрут по умолчанию» (Default Route) или «Шлюз последней надежды» (gateway of last resort). На самом деле в нем нет ничего магического и он просто включает все возможные адреса IPv4, но данные названия хорошо описывают его задачу — он указывает на шлюз, куда пересылать пакеты для которых нет других, более точных, маршрутов.

Максимально возможная маска подсети для IPv4 — /32, такой маршрут указывает на конкретный хост и может использоваться в таблице маршрутизации.

Понимание More Specific Route является фундаментальным для любых устройств работающих с TCP/IP.

Distance

Дистанции (или Метрики) необходимы для административной фильтрации маршрутов до одной подсети доступной через несколько шлюзов. Маршрут с меньшей метрикой считается приоритетным и попадет в FIB. Если маршрут с меньшей метрикой перестанет быть активным, то в FIB он будет заменен на маршрут с большей метрикой.

Если присутствует несколько маршрутов до одной подсети с одинаковой метрикой, маршрутизатор добавить в таблицу FIB только один из них, руководствуясь своей внутренней логикой.

Метрика может принимать значение от 0 до 255:

Check gateway

Check gateway — расширение MikroTik RoutesOS для проверки доступности шлюза по icmp или arp. Раз в 10 секунд (изменить нельзя) на шлюз отправляется запрос, если дважды не приходит ответ маршрут считается недоступным и удаляется из FIB. Если check gateway отключил маршрут проверки продолжается и маршрут снова станет активным после одной успешной проверки.

Check gateway отключает запись, в которой он настроен и все остальные записи (во всех таблицах маршрутизации и ecmp маршрутах) с указанным шлюзом.

В целом check gateway работает нормально, если не возникает проблем с потерей пакетов до шлюза. Check gateway не знает, что происходит со связью за пределами проверяемого шлюза, для этого необходимы дополнительные инструменты: скрипты, рекурсивная маршрутизация, протоколы динамической маршрутизации.

Большинство VPN и туннельных протоколов содержат встроенные средства для проверки активности соединения, включать для них check gateway — это дополнительная (но очень маленькая) нагрузка на сеть и производительность устройства.

ECMP маршруты

Equal-Cost Multi-Path — отправка пакетов до получателя используя одновременно несколько шлюзом с перебором по алгоритму Round Robin.

ECMP маршрут создается администратором, путем указания нескольких gateway для одной подсети (либо автоматический, при наличии двух равноценных маршрутов OSPF).

ECMP используется для балансировки нагрузки между двумя каналами, в теории, если в ecmp маршруте два канала, то для каждого пакета исходящий канал должен отличаться. Но механизм Routing cache отправляет пакеты из соединения по маршруту, которым пошел первый пакет, в итоге получаем подобие балансировки на базе соединений (per-connection loading balancing).

Если отключить Routing Cache, то пакеты в ECMP маршруте будут делиться правильно, но возникает проблема с NAT. Правило NAT обрабатывает только первый пакет из соединения (остальные обрабатываются автоматически) и получается ситуация, что с различных интерфейсов уходят пакеты с одним адресом источника.

В ECMP маршрутах не работает check gateway (баг RouterOS). Но можно обойти это ограничение, если создать дополнительные маршруты для проверки, которые будут отключать записи в ECMP.

Фильтрация средствами Routing

Опция Type определяет, что сделать с пакетом:

Фильтрацию обычно используют, когда нужно обезопасить отправку пакетов не по тому пути, конечно можно фильтровать подобное через firewall.

Пара примеров

Для закрепления базовых вещей о маршрутизации.

Типичный домашний роутер

Типичный домашний роутер с PPPoE

Типичный домашний роутер с двумя провайдерами и резервированием

Трафик до 0.0.0.0/0 идет через 10.10.10.1, пока данный шлюз доступен, иначе переключается на 10.20.20.1

Такую схему можно считать резервированием канала, но она не лишена недостатков. Если произойдет обрыв за пределами шлюза провайдера (например внутри операторской сети), ваш роутер об этом не узнает и продолжит считать маршрут активным.

Типичный домашний роутер с двумя провайдерами, резервированием и ECMP

Маршруты для проверки синего цвета (цвет неактивных маршрутов), но это не мешает работе check gateway. В текущей версии (6.44) RoS автоматический приоритет отдается ECMP маршруту, но лучше добавить проверочные маршруты в другие таблицы маршрутизации (опция routing-mark )

На Speedtest и прочих подобных сайтах прироста скорости не будет (ECMP делит трафик по соединениям, а не по пакетам), но p2p приложения должны загружать быстрее.

Фильтрация через Routing

Вариант фильтрации при которой туннельный трафик не уйдет на маршрутизатор провайдера при отключении ipip интерфейса. Подобные схемы требуются редко, т.к. можно реализовать блокировку через firewall.

Routing Loop
Петля маршрутизации — ситуация когда пакет бегает между маршрутизаторами до истечения ttl. Обычно является следствием ошибки конфигурации, в больших сетях лечится внедрением протоколов динамической маршрутизации, в маленьких — внимательностью.

Выглядит это примерно так:

Пример (наипростейший) как получить подобный результат:

Пример с Routing loop не имеет практического применения, но он показывает что маршрутизаторы понятия не имеют о таблице маршрутизации своих соседей.

Policy Base Routing и дополнительные таблицы маршрутизации

При выборе маршрута, роутер использует только одно поле из заголовка пакета (Dst. Address) — это базовая маршрутизация. Маршрутизация на базе других условий, например адреса источника, типа трафика (ToS), балансировка без ECMP, относится к Policy Base Routing (PBR) и использует дополнительные таблицы маршрутизации.

More Specific Route является основным правилом выбора маршрута, в пределах таблицы маршрутизации.

По умолчанию все правила маршрутизации добавляются в таблицу main. Администратор может создать произвольное количество дополнительных таблиц маршрутизации и направлять пакеты в них. Правила в разных таблицах не конфликтуют между собой. Если пакет не нашел подходящего правила в указанной таблице, он уйдет в таблицу main.

Пример с распределением через Firewall:

Проблемы терминологии

В RouterOS есть определенные проблемы с терминологией.
При работе с правилами в [IP]->[Routes] указывается таблица маршрутизации, хотя и написано что метка:

В [IP]->[Routes]->[Rule] все правильно, в условии метки в действии таблицы:

Как отправить пакет в определенную таблицу маршрутизации

RouterOS дает несколько инструментов:

Правила [IP]->[Route]->[Rules]
Правила обрабатываются последовательно, если пакет совпал с условиями правила он не проходит дальше.

Routing Rules позволяют расширить возможности маршрутизации, опираясь не только на адрес получателя, но и адрес источника и интерфейс на который был получен пакет.

Правила состоят из условий и действия:

В FIB трафик до локальных процессов обрабатывается в обход правил [IP]->[Route]->[Rules] :

Маркировка [IP]->[Firewall]->[Mangle]
Маршрутные метки позволяют устанавливать шлюз для пакета используя практически любые условия Firewall:

Практически, потому что не все из них имеет смысл, а некоторые могут работать нестабильно.

Маркировать пакет можно двумя способами:

В статье про firewall я писал, что второй вариант предпочтительнее т.к. снижает нагрузку на cpu, в случае с маркировкой маршрутов — это не совсем так. Указанные способы маркировки не всегда являются равноценными и обычно используются для решения различных задач.

Примеры использования

Переходим к примерам использования Policy Base Routing, на них гораздо проще показать зачем все это нужно.

MultiWAN и ответный исходящий (Output) трафик
Распространенная проблема, при MultiWAN конфигурации: Mikrotik доступен из сети интернет только по «активному» провайдеру.

Роутеру не важно на какой ip пришел запрос, при генерации ответа он будет искать маршрут в таблице маршрутизации, где активен маршрут через isp1. Дальше такой пакет скорее всего будет отфильтрован по пути до получателя.

Еще один интересный момент. Если на интерфейсе ether1 настроен «простой» source nat: /ip fi nat add out-interface=ether1 action=masquerade пакет уйдет в сеть с src. address=10.10.10.100, что еще больше усугубит ситуацию.

Исправить проблему можно нескольким способами, но для любого из них потребуются дополнительные таблицы маршрутизации:

Использование [IP]->[Route]->[Rules]
Указываем таблицу маршрутизации которая будет использована для пакетов с указанными Source IP.

Данный способ не требует рабочий Connection Tracker, в отличии от использования таблицы Mangle.

Использование [IP]->[Firewall]->[Mangle]
Соединение начинается со входящего пакета, поэтому маркируем его ( action=mark-connection ), для исходящих пакетов от маркированного соединения устанавливаем маршрутную метку ( action=mark-routing ).

Если на одном интерфейсе настроено несколько ip, можно добавить в условие dst-address для уточнения.

MultiWAN и ответный dst-nat трафик

Пример посложнее, что делать если за роутером находится сервер (например web) в частной подсети и необходимо обеспечить доступ к нему по любому из провайдеров.

Суть проблемы будет та же, решение похоже на вариант с Firewall Mangle, только будут использоваться другие цепочки:

На схеме не отображен NAT, но думаю и так все понятно.

MultiWAN и исходящие соединения

Можно использовать возможности PBR для создания нескольких vpn (в примере SSTP) соединений с разных интерфейсов роутера.

Дополнительные таблицы маршрутизации:

Простые правила NAT, иначе пакет уйдет с интерфейса с неправильным Src. Address:

Интересно, что на роутере вы увидите следующую таблицу соединений:

На VPN сервере (на тестовом стенде он у меня один) можно увидеть что все соединения происходят с правильных адресов:

Постой способ
Есть способ проще, можно просто указать определенный шлюз для каждого из адресов:

Распределение соединений пользователей по каналам связи

Простые, повседневные задачи. Опять же понадобятся дополнительные таблицы маршрутизации:

Используя [IP]->[Route]->[Rules]

Используя маркировки в [IP]->[Firewall]->[Mangle]
Простой пример со списками ip адресов. В принципе можно использовать практически любые условия. Единственное предостережение layer7, даже в паре с метками соединений, может показаться что всё работает правильно, но часть трафика всеравно уйдет не туда.

«Запереть» пользователей в одной таблице маршрутизации можно через [IP]->[Route]->[Rules] :

Либо через [IP]->[Firewall]->[Filter] :

В примере с использованием [IP]->[Route]->[Rules] подобных исключений нет, но трафик до локальных процессов доходит. Дело в том, что попадая в FIB пакет промаркированный в [PREROUTING|Mangle] имеет маршрутную метку и уходит в таблицу маршрутизации отличную от main, где нет локального интерфейса. В случае с Routing Rules, сначала проверяется предназначен ли пакет локальному процессу и только на этапе User PBR он уходит в заданную таблицу маршрутизации.

Используя [IP]->[Firewall]->[Mangle action=route]
Данное действие работает только в [Prerouting|Mangle] и позволяет направлять трафик на указанный шлюз без использования дополнительных таблиц маршрутизации, указывая адрес шлюза напрямую:

Динамическая балансировка на основе PPC

Per Connection Classificator — является более гибким аналогом ECMP. В отличии от ECMP делит трафик по соединениям более строго (ECMP ничего про соединения не знает, но в паре с Routing Cache получается нечто похожее).

PCC берет указанные поля из ip заголовка, преобразует их в 32-битное значение и делит на знаменатель. Остаток от деления сравнивается с указанным остатком и если они совпадают, то применяется указанное действие. Подробнее. Звучит дико, но работает.

Пример с тремя адресами:

Пример динамического распределения трафика по src.address между тремя каналами:

Переключение каналов связи

Check ping — хороший инструмент, но он проверяет связь только с ближайшим IP пиром, сети провайдеров обычно состоят из большого числа маршрутизаторов и обрыв связи может произойти за пределами ближайшего пира, а дальше идут магистральные операторы связи у которых тоже могут случаться проблемы, в общем check ping не всегда показывает актуальную информацию о доступе в глобальную сеть.
Если у провайдеров и крупных корпораций есть протокол динамической маршрутизации BGP, то домашним и офисным пользователем приходится самостоятельно придумывать как проверять доступ в интернет через определенный канал связи.

Обычно используются скрипты, которые через определенный канал связи проверяют доступность ip адреса в сети интернет, при этом выбирается что то надежное, например google dns: 8.8.8.8. 8.8.4.4. Но в сообществе Mikrotik для этого приспособили более интересный инструмент.

Пара слов про рекурсивную маршрутизацию
Рекурсивная маршрутизация необходима при построении Multihop BGP пиринга и в статью про основы статической маршрутизации попала только за счет ушлых пользователей MikroTik, которые придумали как использовать рекурсивный маршруты в паре с check gateway для переключение каналов связи без дополнительных скриптов.

Пришло время в общих чертах разобраться с опциями scope/target scope и каким образом маршрут привязывается к интерфейсу:

При наличии рекурсивного маршрута происходит все тоже самое, но в два этапа:

Пример использования рекурсивной маршрутизации для переключения маршрутов

Конфигурация:

Можно проверить, что пакеты будут отправляться на 10.10.10.1:

Check gateway ничего не знает про рекурсивную маршрутизацию и просто отправляет ping’и на адрес 8.8.8.8, который (исходя из таблицы main) доступен через шлюз 10.10.10.1.

Если происходит потеря связи между 10.10.10.1 и 8.8.8.8, то происходит отключение маршрута, но пакеты (включая проверочные ping) до 8.8.8.8 продолжают идти через 10.10.10.1:

Если происходит потеря линка на ether1, то получается неприятная ситуация, когда пакеты до 8.8.8.8 пойдут через второго провайдера:

Это проблема, если вы используете NetWatch для запуска скриптов при недоступности 8.8.8.8. При обрыве линка NetWatch просто отработает по резервному каналу связи и будет считать что все нормально. Решается добавлением дополнительного фильтрующего маршрута:

На хабре есть статья, где ситуация с NetWatch рассмотрена более детально.

И да, при использовании подобного резервирования адрес 8.8.8.8 будет жестко привязан к одному из провайдеров, соответственно выбирать его в качестве источника dns не самая хорошая идея.

Пара слов про Virtual Routing and Forwarding (VRF)

Технология VRF предназначена для создания нескольких виртуальных маршрутизаторов внутри одного физического, данная технология широко применяется у операторов связи (обычно в связке с MPLS) для предоставления услуги L3VPN клиентам с пересекающимися адресами подсетей:

Но VRF в Mikrotik организован на базе таблиц маршрутизации и имеет ряд недостатков, например локальные ip адреса роутера доступны из всех VRF, подробнее можно почитать по ссылке.

Пример конфигурации vrf:

С устройства подключенного к ether2 видим, что проходит ping до адреса роутера из другого vrf (и это проблема), при этом ping в интернет не уходит:

Для доступа в интернет необходимо прописать дополнительный маршрут обращающийся к таблице main (в терминологии vrf это называется route leaking):

И настроить маркировку для ответного трафика в [PREROUTING|Mangle] :

Подсети с одинаковой адресацией
Организация доступа до подсетей с одинаковой адресацией на одном роутере используя VRF и netmap:

Правила маршрутизации для возвратного трафика:

Добавление маршрутов полученных по dhcp в заданную таблицу маршрутизации
VRF может быть интересен, если необходимо автоматически добавить динамический маршрут (например от dhcp client) в определенную таблицу маршрутизации.

Добавление интерфейса в vrf:

Правила для отправки трафика (исходящего и транзитного) через таблицу over-isp1:

Дополнительный, фейковый маршрут для работы исходящей маршрутизции:

Этот маршрут необходим только чтобы локальные исходящие пакеты могли пройти через Routing decision (2) до [OUTPUT|Mangle] и получить маршрутную метку, если на маршрутизаторе есть другие активные маршруты до 0.0.0.0/0 в таблице main оно не требуется.

Фильтрация маршрутов (входящий и исходящих) — это инструмент который обычно используется вместе с протоколами динамической маршрутизации (поэтому доступен только после установки пакета routing), но во входящих фильтрах есть две интересные цепочки:

Это очень точечный инструмент и если можете сделать что-то без Routing Filters (но не скриптами), то не используйте Routing Filters, не путайте себя и тех кто будет конфигурировать роутер после вас. В контексте динамической маршрутизации Routing Filters будут использоваться значительно чаще и продуктивнее.

Установка Routing Mark для динамических маршрутов
Пример с домашнего маршрутизатора. У меня настроено два VPN соединения и трафик в них должен заворачиваться в соответствием с таблицами маршрутизации. При этом я хочу что-бы маршруты создавались автоматически при активации интерфейса:

Не знаю почему, наверное баг, но если создать vrf для ppp интерфейса, то маршрут до 0.0.0.0/0 всеравно попадет в таблицу main. Иначе всё было бы еще проще.

Отключение Connected маршрутов
Иногда требуется и такое:

Инструменты отладки

RouterOS предоставляет ряд средств для отладки маршрутизации:

Источник