Net-Labs.in
Network, ISP
VRF (L3VPN) в Mikrotik RouterOS: defective by design
VRF(L3VPN) в Mikrotik RouterOS реализован с помощью таблиц маршрутизации Linux, однако такой способ построения VRF не является полноценным, это связано с тем, что таблицы policy based routing (ip rule), RT local, arp/nd, firewall остаются общими. Кроме того, 0-ое правило PBR (0: from all lookup local) в старых версиях ядра линукс(
Сначала настроим только интерфейсы ether1 и ether2 в mikrotik:
Проверим как оно выглядит в таблицах маршрутизации микротика:
Теперь запустим пинги с CE1:
Строка 1 – пинг до шлюза, всё ок. Строка 6 – пинг до CE2, которая находится в другом VRF, связности нет, всё правильно. Строка 11 – пинг до шлюза, который находится в другом VRF, связность есть, но её не должно было быть.
Далее, отключим eth2 на микротике и включим eth3:
Связность между CE1 и CE3, естественно есть (ведь это 2 устройства в одном VRF)
Здесь стоит обратить внимание, что ttl=63, потому что пакет прошёл через маршрутизатор, который вычел 1 из 64. В следующем эксперименте это пригодится.
Наконец, включаем все 3 интерфейса на mikrotik:
И запускаем пинги с CE1:
Как видно, теперь ttl=64, что означает, что это отвечает сам микротик, а не CE3, как хотелось бы (если запустить снифер на CE3, то, действительно, трафик не приходит на CE3). При этом с CE3 и CE2 недоступны шлюзы:
Это происходит по причине того, что IP-адреса 192.0.2.5 и 192.0.2.6 принадлежат интерфейсам микротика (хотя и в других VRF).
При такой реализации VRF, область применения сразу же ограничивается. Одно из основных преимуществ (нормального) L3VPN в том, что заказчик самостоятельно планирует своё адресное пространство. И если заказчиков будет больше одного, то возможно пересечение и неработоспособность конкретных хостов. И даже при одном заказчике(который сам разрабатывает адресный план) возможно пересечение с глобальной таблицей маршрутизации, особенно если используются серые адреса в GRT.
Однако для внутренних нужд такую недореализацию иногда можно использовать, например, чтобы спрятать управление L2-оборудованием, UPS-ами, розетками и т.п. в отдельные VRF и не городить лишние access-list’ы.
Полноценная реализация VRF-lite есть в ванильном ядре linux(netns). Относительно дешёвые варианты MPLS L3VPN сейчас есть и продолжают развиваться на китайских L3-свитчах. Возможно, когда-нибудь и микротик перейдут на netns, скрестят с ним свою реализацию MPLS, возможно, добавят костылей вида удаления 0-го правила из ip rule, включат accept_local или же оставят всё как есть. Для SOHO оборудования и так функционал выше среднего.
Mikrotik VRF+NAT — Управляем с одного хоста устройствами с одинаковыми IP-адресами
Недавно знакомый попросил помощи с настройкой микротика. Просьба была не совсем простая. Идея в том, что нужно было одновременно управлять с одного хоста четырьмя устройствами с неуправляемым TCP/IP стеком. На всех этих устройствах были одинаковые настройки IP, причем просто IP-адрес и маска, ни шлюз, ни DNS не указаны. Странная, но, как оказалось, весьма реальная ситуация. Не будем вдаваться в подробности причин невозможности перенастройки адресации на этих устройствах, а просто примем этот факт за аксиому. Задача поставлена так, как есть, и ее нужно решить.
Итак, исходные данные:
1. Четыре устройства с одинаковыми настройками IP — 192.168.1.1/24; GW и DNS не указаны; изменить эти настройки невозможно.
2. ПК, с которого необходимо одновременно иметь доступ ко всем четырем устройствам, допустим на WEB-интерфейс.
3. Простенький MikroTik RB750GL на 5 портов.
MikroTik RB750GL с настройками по умолчанию использует 1 порт для подключения к Интернету (NAT, FW), а остальные порты для подключения к локальной сети с настроенным DHCP — как обычный домашний роутер или роутер Small Business серии. Нам нужно задействовать все 5 портов, поэтому для начала полностью чистим конфиг и избавляемся от NAT, FW и DHCP.
Итак, кофиг очистили, собираем схему: 
Теперь к делу…
Первая и основная проблема, которая встает перед нами — это использование одинаковых IP-адресов или IP-адресов из одной подсети на разных интерфейсах маршрутизатора для обеспечения сетевой доступности целевых устройств. Как трактуют основы сетевого взаимодействия с одной таблицей маршрутизации такое сделать невозможно. Значит надо сделать несколько таблиц маршрутизации, и в этом нам поможет Virtual Routing and Forwarding (VRF). Не будем сильно погружаться в VRF — нам достаточно просто поместить разные интерфейсы в разные таблицы маршрутизации:
/ip route vrf
add interfaces=ether1 routing-mark=DEV1
add interfaces=ether2 routing-mark=DEV2
add interfaces=ether3 routing-mark=DEV3
add interfaces=ether4 routing-mark=DEV4
Отлично. Теперь настроим IP-адресацию согласно схеме:
IP-адрес 192.168.2.1 будет использоваться для доступа к менеджменту самого MikroTik’а:
/ip address
add address=192.168.2.1/24 interface=ether5 network=192.168.2.0
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
add address=192.168.1.2/24 interface=ether2 network=192.168.1.0
add address=192.168.1.2/24 interface=ether3 network=192.168.1.0
add address=192.168.1.2/24 interface=ether4 network=192.168.1.0
Вспомним, что на самих устройствах, которыми нужно управлять, также отсутствует возможность настройки шлюза по умолчанию. Еще нам нужно как-то разделять эти устройства для доступа с MGMT PC. Естественно NAT. Для каждого устройства выделим IP из подсети 192.168.2.0/24 и настроим на интерфейсе ether5:
/ip address
add address=192.168.2.11/24 interface=ether5 network=192.168.2.0
add address=192.168.2.12/24 interface=ether5 network=192.168.2.0
add address=192.168.2.13/24 interface=ether5 network=192.168.2.0
add address=192.168.2.14/24 interface=ether5 network=192.168.2.0
Сам NAT пока не трогаем и вспоминаем, что наши пакеты должны «бегать» между разными таблицами маршрутизации. Для этого нужно ставить маршрутные метки согласно новым IP-адресам, которые в дальнейшем будем NAT’ировать. Согласно документации NetFilter таблица Mangle, которая отвечает за маркировку трафика, отрабатывает раньше таблицы NAT. Опираясь на этот факт делаем следующее:
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.2.11 new-routing-mark=DEV1
add action=mark-routing chain=prerouting dst-address=192.168.2.12 new-routing-mark=DEV2
add action=mark-routing chain=prerouting dst-address=192.168.2.13 new-routing-mark=DEV3
add action=mark-routing chain=prerouting dst-address=192.168.2.14 new-routing-mark=DEV4
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.2.2 new-routing-mark=main
На основе данного правила все пакеты с адресом назначения 192.168.2.2 будут перекладываться в основную таблицу маршрутизации «main», в которой и находится интерфейс хоста управления.
Осталось подумать о NAT. Для каждого устройства у нас будет по два правила:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.2.11 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether1 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.12 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether2 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.13 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether3 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.14 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether4 to-addresses=192.168.1.2
Manual:Virtual Routing and Forwarding
Applies to RouterOS: 3, v4+
Packages required: routing-test, mpls-test for RouterOS v3; routing, mpls for RouterOS v4+
Contents
Description
RouterOS 3.x allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP based MPLS VPNs. Unlike BGP VPLS, which is OSI Layer 2 technology, BGP VRF VPNs work in Layer 3 and as such exchange IP prefixes between routers. VRFs solve the problem of overlapping IP prefixes, and provide the required privacy (via separated routing for different VPNs).
Technically VRFs are based on policy routing. There is exactly one policy route table for each active VRF. The existing policy routing support in MT RouterOS is not changed; but on the other hand, it is not possible to have policy routing within a VRF. The main differences between VRF tables and simple policy routing are:
Note: When a DHCP-Relay server is attached to an interface in a vrf, the communications from that DHCP-Relay to the remote DHCP-Server will not be routed via the vrf!
Once list of VRFs for BGP instance, route distinguisher and export route targets has been configured, some active VPNv4 address family routes may be created, depending on BGP redistribution settings. They are installed in a separate route table and, if present, visible under /routing bgp vpnv4-route. These so called VPNv4 routes have prefix that consists of a route distinguisher and an IPv4 network prefix. This way you can have overlapping IPv4 prefixes distributed in BGP.
Please note that a VPNv4 route will be distributed only if it has a valid MPLS label. You need to install mpls-test package and configure valid label range for this to work. (Default configuration has valid label range.)
Examples
The simplest MPLS VPN setup
In this example rudimentary MPLS backbone (consisting of two Provider Edge (PE) routers PE1 and PE2) is created and configured to forward traffic between Customer Edge (CE) routers CE1 and CE2 routers that belong to cust-one VPN.
CE1 Router
CE2 Router
PE1 Router
PE2 Router (Cisco)
Results
Check that VPNv4 route redistribution is working:
Check that the 10.3.3.0 is installed in IP routes, in cust-one route table:
Let’s take closer look at IP routes in cust-one VRF. The 10.1.1.0/24 IP prefix is a connected route that belongs to an interface that was configured to belong to cust-one VRF. The 10.3.3.0/24 IP prefix was advertised via BGP as VPNv4 route from PE2 and is imported in this VRF routing table, because our configured import-route-targets matched the BGP extended communities attribute it was advertised with.
The same for Cisco:
You should be able to ping from CE1 to CE2 and vice versa.
A more complicated setup (changes only)
As opposed to the simplest setup, in this example we have two customers: cust-one and cust-two.
We configure two VPNs for then, cust-one and cust-two respectively, and exchange all routes between them. (This is also called «route leaking»).
Note that this could be not the most typical setup, because routes are usually not exchanged between different customers. In contrast, by default it should not be possible to gain access from one VRF site to a different VRF site in another VPN. (This is the «Private» aspect of VPNs.) Separate routing is a way to provide privacy; and it is also required to solve the problem of overlapping IP network prefixes. Route exchange is in direct conflict with these two requirement but may sometimes be needed (e.g. temp. solution when two customers are migrating to single network infrastructure).
CE1 Router, cust-one
CE2 Router, cust-one
CE1 Router, cust-two
PE1 Router
PE2 Router (Cisco)
Variation: replace the Cisco with another MT
PE2 Mikrotik config
Results
The output of /ip route print now is interesting enough to deserve detailed observation.
The route 10.1.1.0/24 was received from remote BGP peer and is installed in both VRF routing tables.
The routes 10.3.3.0/24 and 10.4.4.0/24 are also installed in both VRF routing tables. Each is as connected route in one table and as BGP route in another table. This has nothing to do with their being advertised via BGP. They are simply being «advertised» to local VPNv4 route table and locally reimported after that. Import and export route-targets determine in which tables they will end up.
Static inter-VRF routes
In general it is recommended that all routes between VRF should be exchanged using BGP local import and export functionality. If that is not enough, static routes can be used to achieve this so-called route leaking.
There are two ways to install a route that has gateway in different routing table than the route itself.
The first way is to explicitly specify routing table in gateway field when adding route. This is only possible when leaking a route and gateway from the «main» routing table to a different routing table (VRF). Example:
The second way is to explicitly specify interface in gateway field. The interface specified can belong to a VRF instance. Example:
References
MPLS Fundamentals, chapter 7, Luc De Ghein, Cisco Press 2006
Основы статической маршрутизации в 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 предоставляет ряд средств для отладки маршрутизации: