mikrotik-wiki.ru
Главная
Загрузка...

VRF на MikroTik — виртуальные таблицы маршрутизации

RouterOS 7.xRouting11 мин130 мар. 2026 г.
TelegramVK

VRF (Virtual Routing and Forwarding) — технология, позволяющая создать несколько изолированных таблиц маршрутизации на одном маршрутизаторе. Каждая VRF-таблица функционирует как отдельный виртуальный роутер: IP-адреса, маршруты и интерфейсы в разных VRF не пересекаются. Это базовая технология для провайдеров, дата-центров и организаций, обслуживающих несколько клиентов с пересекающимися адресными пространствами. В RouterOS 7 VRF полностью переработан: используется /ip/vrf и /routing/table вместо устаревших конструкций из RouterOS 6.

Описание

Зачем нужен VRF

Представьте ситуацию: вы — провайдер или MSP (Managed Service Provider), обслуживающий трёх клиентов. Все три клиента используют подсеть 192.168.1.0/24 для своих локальных сетей. Без VRF это невозможно — маршрутизатор не может иметь три маршрута к 192.168.1.0/24 с разными next-hop в одной таблице маршрутизации.

С VRF каждый клиент получает собственную таблицу маршрутизации. Маршруты в таблице клиента A не видны клиенту B, и наоборот.

Типичные сценарии использования:

СценарийОписание
ISP multi-tenantНесколько клиентов с пересекающимися подсетями
Изоляция сегментовРазделение production и management сетей
MPLS L3VPNVRF как endpoint для MP-BGP VPNv4
БезопасностьПолная изоляция трафика без физического разделения
ТестированиеИзолированная среда для тестов без влияния на production

Ключевые концепции

VRF instance — виртуальная таблица маршрутизации с собственным набором интерфейсов, IP-адресов и маршрутов. Создаётся через /ip/vrf.

Routing table — таблица маршрутизации, привязанная к VRF. В RouterOS 7 routing table создаётся отдельно через /routing/table и ассоциируется с VRF.

Route Distinguisher (RD) — 64-битный идентификатор, делающий маршруты уникальными в контексте MP-BGP. Формат: ASN:число или IP:число. Используется только при интеграции с MPLS/BGP.

Route Target (RT) — определяет правила импорта/экспорта маршрутов между VRF. Import RT — какие маршруты принимать, Export RT — какие маршруты объявлять.

VRF Leaking — контролируемая утечка маршрутов между VRF. Позволяет, например, дать всем VRF доступ к общему DNS-серверу или интернету.

Схема сети

code
                [MikroTik Router]
                     │
     ┌───────────────┼───────────────┐
     │               │               │
   ether2          ether3          ether4
  VRF: client-a   VRF: client-b   VRF: client-c
  192.168.1.1/24  192.168.1.1/24  192.168.1.1/24
     │               │               │
  [Client A]      [Client B]      [Client C]
  192.168.1.0/24  192.168.1.0/24  192.168.1.0/24

Три клиента с одинаковой адресацией подключены к одному роутеру через разные интерфейсы и изолированы через VRF.

Настройка

Шаг 1: Создание VRF

В RouterOS 7 VRF создаётся через /ip/vrf. Каждый VRF привязывается к интерфейсам и получает собственную таблицу маршрутизации.

[admin@MikroTik] >
/ip/vrf add name=client-a interfaces=ether2
/ip/vrf add name=client-b interfaces=ether3
/ip/vrf add name=client-c interfaces=ether4

После этой команды интерфейсы ether2, ether3 и ether4 помещаются в соответствующие VRF. Трафик на этих интерфейсах изолирован от main routing table.

Шаг 2: Routing tables

Для каждого VRF создаём именованную таблицу маршрутизации:

[admin@MikroTik] >
/routing/table add name=client-a fib
/routing/table add name=client-b fib
/routing/table add name=client-c fib

Параметр fib указывает, что таблица активно используется для forwarding (Forwarding Information Base).

Шаг 3: IP-адреса в VRF

Назначаем IP-адреса на интерфейсы, находящиеся в VRF:

[admin@MikroTik] >
/ip/address add address=192.168.1.1/24 interface=ether2
/ip/address add address=192.168.1.1/24 interface=ether3
/ip/address add address=192.168.1.1/24 interface=ether4

Обратите внимание: все три адреса одинаковы (192.168.1.1/24). Это возможно, потому что интерфейсы находятся в разных VRF — конфликта нет.

Шаг 4: Маршруты в VRF

Статические маршруты добавляются с указанием routing-table:

[admin@MikroTik] >
# Маршрут в сеть за клиентом A (если за ним есть ещё подсети)
/ip/route add dst-address=10.10.1.0/24 gateway=192.168.1.2 routing-table=client-a

# Маршрут в сеть за клиентом B
/ip/route add dst-address=10.10.2.0/24 gateway=192.168.1.2 routing-table=client-b

# Default route для каждого клиента (выход в интернет)
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-a
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-b
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-c

Шаг 5: DHCP-сервер в VRF

Каждый VRF может иметь собственный DHCP-сервер:

[admin@MikroTik] >
# Pool для клиента A
/ip/pool add name=pool-client-a ranges=192.168.1.100-192.168.1.200

# DHCP Server для клиента A
/ip/dhcp-server add name=dhcp-client-a interface=ether2 \
    address-pool=pool-client-a lease-time=12h

/ip/dhcp-server/network add address=192.168.1.0/24 gateway=192.168.1.1 \
    dns-server=192.168.1.1

# Аналогично для клиентов B и C
/ip/pool add name=pool-client-b ranges=192.168.1.100-192.168.1.200
/ip/dhcp-server add name=dhcp-client-b interface=ether3 \
    address-pool=pool-client-b lease-time=12h

/ip/pool add name=pool-client-c ranges=192.168.1.100-192.168.1.200
/ip/dhcp-server add name=dhcp-client-c interface=ether4 \
    address-pool=pool-client-c lease-time=12h

Шаг 6: NAT для VRF

Для предоставления доступа в интернет каждому VRF нужен NAT. WAN-интерфейс (ether1) находится в main VRF. Нужно «пробросить» трафик из VRF в main.

Вариант 1 — NAT с routing-mark:

[admin@MikroTik] >
# Mangle: маркируем трафик из каждого VRF
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-a to main"

/ip/firewall/mangle add chain=prerouting in-interface=ether3 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-b to main"

/ip/firewall/mangle add chain=prerouting in-interface=ether4 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-c to main"

# NAT
/ip/firewall/nat add chain=srcnat out-interface=ether1 action=masquerade

Вариант 2 — default route в VRF через WAN gateway (если WAN-интерфейс доступен из VRF):

[admin@MikroTik] >
# Добавляем WAN-интерфейс в VRF (не рекомендуется для shared WAN)
# Лучше использовать вариант 1 с mangle

VRF Leaking — обмен маршрутами между VRF

Концепция

VRF Leaking позволяет контролируемо «просочить» определённые маршруты из одного VRF в другой. Типичные сценарии:

  • Все клиенты должны иметь доступ к общему DNS-серверу в main VRF
  • Management-сеть должна видеть все клиентские VRF
  • Shared services (NTP, logging) доступны из всех VRF

Настройка VRF Leaking через статические маршруты

В RouterOS 7 простейший способ — статический маршрут с указанием gateway из другого VRF:

[admin@MikroTik] >
# DNS-сервер 10.0.0.53 находится в main VRF
# Делаем его доступным из client-a VRF

# Маршрут в client-a, указывающий на шлюз в main
/ip/route add dst-address=10.0.0.53/32 gateway=ether1 routing-table=client-a

Для обратного маршрута (чтобы DNS-сервер мог ответить клиентам):

[admin@MikroTik] >
/ip/route add dst-address=192.168.1.0/24 gateway=ether2 routing-table=main

Внимание: при одинаковых подсетях обратный маршрут неоднозначен. В этом случае используйте NAT в VRF, чтобы клиентский трафик к shared services приходил с уникальным адресом.

VRF + OSPF

OSPF может работать внутри VRF, строя отдельную таблицу маршрутизации для каждого VRF.

[admin@MikroTik] >
# OSPF instance для client-a
/routing/ospf/instance add name=ospf-client-a router-id=1.1.1.1 \
    routing-table=client-a vrf=client-a

# OSPF area
/routing/ospf/area add name=backbone-client-a instance=ospf-client-a area-id=0.0.0.0

# OSPF interface-template
/routing/ospf/interface-template add area=backbone-client-a interfaces=ether2 \
    type=ptp

Аналогично для каждого VRF, если в клиентской сети используется OSPF для динамической маршрутизации.

VRF + BGP (MP-BGP VPNv4)

Для полноценных L3VPN через MPLS используется MP-BGP с address-family VPNv4. Каждый VRF получает Route Distinguisher (RD) и Route Target (RT).

Настройка BGP с VPNv4

[admin@MikroTik] >
# BGP instance
/routing/bgp/template add name=ibgp-vpnv4 as=65000 \
    address-families=vpnv4

# BGP peer (PE-PE iBGP)
/routing/bgp/connection add name=pe2 template=ibgp-vpnv4 \
    remote.address=10.0.0.2 remote.as=65000 \
    local.role=ibgp

VRF с RD и RT

[admin@MikroTik] >
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100

Route Distinguisher делает маршруты уникальными в BGP: маршрут 192.168.1.0/24 в VRF client-a становится 65000:100:192.168.1.0/24.

Route Target определяет политику:

  • export-route-targets=65000:100 — маршруты из этого VRF экспортируются с RT 65000:100
  • import-route-targets=65000:100 — VRF импортирует маршруты с RT 65000:100

Для связи двух VRF (например, client-a на PE1 и client-a на PE2):

  • Оба VRF используют одинаковый RT (65000:100)
  • BGP автоматически распространяет маршруты между PE-роутерами
  • На каждом PE маршруты с соответствующим RT импортируются в нужный VRF

Пример: два PE-роутера, один клиент

PE1 (RouterOS):

[admin@MikroTik] >
# VRF
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100

# IP в VRF
/ip/address add address=192.168.1.1/24 interface=ether2

# BGP к PE2
/routing/bgp/template add name=vpnv4-tmpl as=65000 address-families=vpnv4
/routing/bgp/connection add name=to-pe2 template=vpnv4-tmpl \
    remote.address=10.0.0.2 remote.as=65000 local.role=ibgp

# OSPF в VRF (опционально, для динамического обмена маршрутами с CE)
/routing/ospf/instance add name=ospf-client-a router-id=1.1.1.1 \
    routing-table=client-a vrf=client-a redistribute=bgp
/routing/ospf/area add name=area0-ca instance=ospf-client-a area-id=0.0.0.0
/routing/ospf/interface-template add area=area0-ca interfaces=ether2

PE2 (RouterOS):

[admin@MikroTik] >
# VRF
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100

# IP в VRF
/ip/address add address=192.168.2.1/24 interface=ether2

# BGP к PE1
/routing/bgp/template add name=vpnv4-tmpl as=65000 address-families=vpnv4
/routing/bgp/connection add name=to-pe1 template=vpnv4-tmpl \
    remote.address=10.0.0.1 remote.as=65000 local.role=ibgp

# OSPF в VRF
/routing/ospf/instance add name=ospf-client-a router-id=2.2.2.2 \
    routing-table=client-a vrf=client-a redistribute=bgp
/routing/ospf/area add name=area0-ca instance=ospf-client-a area-id=0.0.0.0
/routing/ospf/interface-template add area=area0-ca interfaces=ether2

В результате CE-устройства клиента A на обоих площадках видят друг друга через MPLS backbone, а их маршруты полностью изолированы от других клиентов.

VRF + NAT

NAT в VRF имеет особенности. Firewall в RouterOS работает в контексте main routing table. Для NAT трафика из VRF нужно сначала перенаправить его в main.

[admin@MikroTik] >
# Маркируем трафик из VRF для перенаправления в main
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address=!192.168.1.0/24 action=mark-routing \
    new-routing-mark=main passthrough=yes

# NAT
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    src-address=192.168.1.0/24 action=src-nat to-addresses=203.0.113.10 \
    comment="NAT for client-a"

Если у каждого клиента должен быть свой внешний IP:

[admin@MikroTik] >
# Client A → 203.0.113.10
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether2 action=src-nat to-addresses=203.0.113.10

# Client B → 203.0.113.11
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether3 action=src-nat to-addresses=203.0.113.11

# Client C → 203.0.113.12
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether4 action=src-nat to-addresses=203.0.113.12

ISP multi-tenant сценарий

Рассмотрим полный пример: провайдер предоставляет интернет и изолированные VPN трём клиентам через один MikroTik.

code
         [Internet]
              │
           ether1
        203.0.113.1/24
              │
     ┌────────┴────────┐
     │   MikroTik PE   │
     │   Main VRF      │
     └┬───────┬────────┬┘
      │       │        │
   ether2   ether3   ether4
   VRF:A    VRF:B    VRF:C
      │       │        │
   [CE-A]  [CE-B]   [CE-C]
[admin@MikroTik] >
# === VRF ===
/ip/vrf add name=vrf-a interfaces=ether2
/ip/vrf add name=vrf-b interfaces=ether3
/ip/vrf add name=vrf-c interfaces=ether4

# === Routing tables ===
/routing/table add name=vrf-a fib
/routing/table add name=vrf-b fib
/routing/table add name=vrf-c fib

# === IP addresses ===
/ip/address add address=203.0.113.10/24 interface=ether1 comment="WAN"
/ip/address add address=10.100.1.1/30 interface=ether2 comment="Link to CE-A"
/ip/address add address=10.100.2.1/30 interface=ether3 comment="Link to CE-B"
/ip/address add address=10.100.3.1/30 interface=ether4 comment="Link to CE-C"

# === Маршруты клиентов ===
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.1.2 routing-table=vrf-a
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.2.2 routing-table=vrf-b
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.3.2 routing-table=vrf-c

# === Default routes для клиентов (интернет) ===
# Через mangle перенаправляем в main для NAT
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether3 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether4 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes

# === NAT ===
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether2 action=src-nat to-addresses=203.0.113.11
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether3 action=src-nat to-addresses=203.0.113.12
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether4 action=src-nat to-addresses=203.0.113.13

# === Default route (WAN) ===
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1

Проверка

Просмотр VRF

[admin@MikroTik] >
/ip/vrf print

Ожидаемый вывод:

code
Flags: X - disabled
 #   NAME       INTERFACES    ROUTE-DISTINGUISHER
 0   main
 1   client-a   ether2
 2   client-b   ether3
 3   client-c   ether4

Просмотр таблиц маршрутизации

[admin@MikroTik] >
/ip/route print where routing-table=client-a

Покажет только маршруты в VRF client-a. Connected-маршруты для ether2 появятся автоматически.

[admin@MikroTik] >
/ip/route print where routing-table=main

Маршруты main VRF — не содержат клиентских подсетей.

Проверка изоляции

Из main VRF невозможно пинговать адреса в клиентских VRF (если не настроен leaking):

[admin@MikroTik] >
/ping 192.168.1.1 vrf=main
# Результат: timeout (адрес недоступен из main)

/ping 192.168.1.1 vrf=client-a
# Результат: reply (адрес доступен в VRF client-a)

Параметр vrf= указывает, из какого VRF выполнять пинг.

Проверка BGP VPNv4

[admin@MikroTik] >
/routing/bgp/session print

Проверяем, что BGP-сессия established и address-family vpnv4 активна.

[admin@MikroTik] >
/routing/bgp/advertisements print where address-family=vpnv4

Показывает маршруты, объявляемые через VPNv4.

Проверка подключённых маршрутов

[admin@MikroTik] >
/ip/route print where routing-table=client-a type=connected

Должен показать connected-маршрут для подсети на ether2.

Типичные ошибки

1. Интерфейс не добавлен в VRF

Проблема: IP-адрес назначен, но трафик идёт через main routing table.

Симптом: клиенты из разных VRF видят друг друга; нет изоляции.

Диагностика:

[admin@MikroTik] >
/ip/vrf print detail
# Проверяем, что интерфейс указан в поле interfaces

Решение:

[admin@MikroTik] >
/ip/vrf set [find name=client-a] interfaces=ether2

2. Routing table не создана

Проблема: VRF создан, но routing table с соответствующим именем отсутствует. Маршруты не добавляются.

Решение:

[admin@MikroTik] >
/routing/table add name=client-a fib

Имя routing table должно точно совпадать с именем VRF.

3. DNS не работает в VRF

Проблема: DNS-сервер роутера работает в main VRF. Клиенты из других VRF не могут его использовать.

Решение 1: настройте DNS-forwarding через mangle:

[admin@MikroTik] >
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-port=53 protocol=udp action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-port=53 protocol=tcp action=mark-routing \
    new-routing-mark=main passthrough=yes

Решение 2: указывайте в DHCP внешний DNS (8.8.8.8), доступный через маршрут в VRF.

4. NAT не работает для VRF-трафика

Проблема: firewall/NAT работает в main VRF. Трафик из клиентских VRF не попадает в NAT.

Решение: используйте mangle для перенаправления трафика из VRF в main (см. раздел «VRF + NAT»).

5. Пересечение IP-адресов в ARP

Проблема: несколько клиентов с одинаковыми IP, но ARP-таблица единая. Возможны ARP-конфликты при определённых конфигурациях bridge.

Решение: не помещайте интерфейсы из разных VRF в один bridge. Каждый VRF должен использовать отдельный интерфейс или отдельный bridge.

[admin@MikroTik] >
# Правильно: отдельные bridge для каждого VRF
/interface/bridge add name=bridge-client-a
/interface/bridge/port add bridge=bridge-client-a interface=ether2
/ip/vrf set [find name=client-a] interfaces=bridge-client-a

6. Забыт обратный маршрут при VRF Leaking

Проблема: маршрут в shared services настроен, трафик уходит, но ответ не возвращается в VRF.

Симптом: пинг уходит, но reply не приходит; tcpdump на сервере показывает входящие пакеты, но ответы теряются.

Решение: всегда настраивайте маршруты в обоих направлениях. Или используйте NAT для упрощения обратной маршрутизации.

7. OSPF/BGP instance не привязан к VRF

Проблема: OSPF работает, но маршруты попадают в main routing table вместо VRF.

Решение: убедитесь, что в OSPF/BGP instance указан правильный routing-table и vrf:

[admin@MikroTik] >
/routing/ospf/instance print detail
# Проверяем поля routing-table и vrf

Мониторинг

Просмотр всех маршрутов по таблицам

[admin@MikroTik] >
# Все маршруты во всех таблицах
/ip/route print

# Фильтр по конкретной таблице
/ip/route print where routing-table=client-a

# Только active маршруты
/ip/route print where routing-table=client-a active=yes

Счётчики интерфейсов

[admin@MikroTik] >
/interface/print stats where name~"ether[2-4]"

Показывает трафик на каждом клиентском интерфейсе.

Трассировка из конкретного VRF

[admin@MikroTik] >
/tool/traceroute 8.8.8.8 vrf=client-a

Показывает маршрут пакета из VRF client-a, включая промежуточные хопы.

Проверка ARP в VRF

[admin@MikroTik] >
/ip/arp print where interface=ether2

ARP-записи отображаются с привязкой к интерфейсу, что позволяет различать записи из разных VRF.

Заключение

VRF — фундаментальная технология сетевой изоляции, необходимая провайдерам, MSP и крупным организациям. В RouterOS 7 настройка VRF интуитивна: создаём /ip/vrf, привязываем интерфейсы, назначаем маршруты в именованных таблицах. Для полноценных L3VPN связка VRF + MP-BGP VPNv4 + MPLS обеспечивает масштабируемое и стандартизированное решение. Ключевое правило: каждый VRF — это отдельный виртуальный роутер, и всё, что нужно для работы сети (маршруты, NAT, DNS), должно быть настроено для каждого VRF отдельно.

[admin@MikroTik] >
[MikroTik Router]
                     │
     ┌───────────────┼───────────────┐
     │               │               │
   ether2          ether3          ether4
  VRF: client-a   VRF: client-b   VRF: client-c
  192.168.1.1/24  192.168.1.1/24  192.168.1.1/24
     │               │               │
  [Client A]      [Client B]      [Client C]
  192.168.1.0/24  192.168.1.0/24  192.168.1.0/24
/ip/vrf add name=client-a interfaces=ether2
/ip/vrf add name=client-b interfaces=ether3
/ip/vrf add name=client-c interfaces=ether4
/routing/table add name=client-a fib
/routing/table add name=client-b fib
/routing/table add name=client-c fib
/ip/address add address=192.168.1.1/24 interface=ether2
/ip/address add address=192.168.1.1/24 interface=ether3
/ip/address add address=192.168.1.1/24 interface=ether4
# Маршрут в сеть за клиентом A (если за ним есть ещё подсети)
/ip/route add dst-address=10.10.1.0/24 gateway=192.168.1.2 routing-table=client-a

# Маршрут в сеть за клиентом B
/ip/route add dst-address=10.10.2.0/24 gateway=192.168.1.2 routing-table=client-b

# Default route для каждого клиента (выход в интернет)
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-a
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-b
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-table=client-c
# Pool для клиента A
/ip/pool add name=pool-client-a ranges=192.168.1.100-192.168.1.200

# DHCP Server для клиента A
/ip/dhcp-server add name=dhcp-client-a interface=ether2 \
    address-pool=pool-client-a lease-time=12h

/ip/dhcp-server/network add address=192.168.1.0/24 gateway=192.168.1.1 \
    dns-server=192.168.1.1

# Аналогично для клиентов B и C
/ip/pool add name=pool-client-b ranges=192.168.1.100-192.168.1.200
/ip/dhcp-server add name=dhcp-client-b interface=ether3 \
    address-pool=pool-client-b lease-time=12h

/ip/pool add name=pool-client-c ranges=192.168.1.100-192.168.1.200
/ip/dhcp-server add name=dhcp-client-c interface=ether4 \
    address-pool=pool-client-c lease-time=12h
# Mangle: маркируем трафик из каждого VRF
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-a to main"

/ip/firewall/mangle add chain=prerouting in-interface=ether3 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-b to main"

/ip/firewall/mangle add chain=prerouting in-interface=ether4 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes comment="VRF client-c to main"

# NAT
/ip/firewall/nat add chain=srcnat out-interface=ether1 action=masquerade
# Добавляем WAN-интерфейс в VRF (не рекомендуется для shared WAN)
# Лучше использовать вариант 1 с mangle
# DNS-сервер 10.0.0.53 находится в main VRF
# Делаем его доступным из client-a VRF

# Маршрут в client-a, указывающий на шлюз в main
/ip/route add dst-address=10.0.0.53/32 gateway=ether1 routing-table=client-a
/ip/route add dst-address=192.168.1.0/24 gateway=ether2 routing-table=main
# OSPF instance для client-a
/routing/ospf/instance add name=ospf-client-a router-id=1.1.1.1 \
    routing-table=client-a vrf=client-a

# OSPF area
/routing/ospf/area add name=backbone-client-a instance=ospf-client-a area-id=0.0.0.0

# OSPF interface-template
/routing/ospf/interface-template add area=backbone-client-a interfaces=ether2 \
    type=ptp
# BGP instance
/routing/bgp/template add name=ibgp-vpnv4 as=65000 \
    address-families=vpnv4

# BGP peer (PE-PE iBGP)
/routing/bgp/connection add name=pe2 template=ibgp-vpnv4 \
    remote.address=10.0.0.2 remote.as=65000 \
    local.role=ibgp
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100
# VRF
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100

# IP в VRF
/ip/address add address=192.168.1.1/24 interface=ether2

# BGP к PE2
/routing/bgp/template add name=vpnv4-tmpl as=65000 address-families=vpnv4
/routing/bgp/connection add name=to-pe2 template=vpnv4-tmpl \
    remote.address=10.0.0.2 remote.as=65000 local.role=ibgp

# OSPF в VRF (опционально, для динамического обмена маршрутами с CE)
/routing/ospf/instance add name=ospf-client-a router-id=1.1.1.1 \
    routing-table=client-a vrf=client-a redistribute=bgp
/routing/ospf/area add name=area0-ca instance=ospf-client-a area-id=0.0.0.0
/routing/ospf/interface-template add area=area0-ca interfaces=ether2
# VRF
/ip/vrf add name=client-a interfaces=ether2 \
    route-distinguisher=65000:100 \
    import-route-targets=65000:100 \
    export-route-targets=65000:100

# IP в VRF
/ip/address add address=192.168.2.1/24 interface=ether2

# BGP к PE1
/routing/bgp/template add name=vpnv4-tmpl as=65000 address-families=vpnv4
/routing/bgp/connection add name=to-pe1 template=vpnv4-tmpl \
    remote.address=10.0.0.1 remote.as=65000 local.role=ibgp

# OSPF в VRF
/routing/ospf/instance add name=ospf-client-a router-id=2.2.2.2 \
    routing-table=client-a vrf=client-a redistribute=bgp
/routing/ospf/area add name=area0-ca instance=ospf-client-a area-id=0.0.0.0
/routing/ospf/interface-template add area=area0-ca interfaces=ether2
# Маркируем трафик из VRF для перенаправления в main
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address=!192.168.1.0/24 action=mark-routing \
    new-routing-mark=main passthrough=yes

# NAT
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    src-address=192.168.1.0/24 action=src-nat to-addresses=203.0.113.10 \
    comment="NAT for client-a"
# Client A → 203.0.113.10
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether2 action=src-nat to-addresses=203.0.113.10

# Client B → 203.0.113.11
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether3 action=src-nat to-addresses=203.0.113.11

# Client C → 203.0.113.12
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether4 action=src-nat to-addresses=203.0.113.12
[Internet]
              │
           ether1
        203.0.113.1/24
              │
     ┌────────┴────────┐
     │   MikroTik PE   │
     │   Main VRF      │
     └┬───────┬────────┬┘
      │       │        │
   ether2   ether3   ether4
   VRF:A    VRF:B    VRF:C
      │       │        │
   [CE-A]  [CE-B]   [CE-C]
# === VRF ===
/ip/vrf add name=vrf-a interfaces=ether2
/ip/vrf add name=vrf-b interfaces=ether3
/ip/vrf add name=vrf-c interfaces=ether4

# === Routing tables ===
/routing/table add name=vrf-a fib
/routing/table add name=vrf-b fib
/routing/table add name=vrf-c fib

# === IP addresses ===
/ip/address add address=203.0.113.10/24 interface=ether1 comment="WAN"
/ip/address add address=10.100.1.1/30 interface=ether2 comment="Link to CE-A"
/ip/address add address=10.100.2.1/30 interface=ether3 comment="Link to CE-B"
/ip/address add address=10.100.3.1/30 interface=ether4 comment="Link to CE-C"

# === Маршруты клиентов ===
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.1.2 routing-table=vrf-a
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.2.2 routing-table=vrf-b
/ip/route add dst-address=192.168.1.0/24 gateway=10.100.3.2 routing-table=vrf-c

# === Default routes для клиентов (интернет) ===
# Через mangle перенаправляем в main для NAT
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether3 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether4 \
    dst-address-type=!local action=mark-routing \
    new-routing-mark=main passthrough=yes

# === NAT ===
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether2 action=src-nat to-addresses=203.0.113.11
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether3 action=src-nat to-addresses=203.0.113.12
/ip/firewall/nat add chain=srcnat out-interface=ether1 \
    in-interface=ether4 action=src-nat to-addresses=203.0.113.13

# === Default route (WAN) ===
/ip/route add dst-address=0.0.0.0/0 gateway=203.0.113.1
/ip/vrf print
Flags: X - disabled
 #   NAME       INTERFACES    ROUTE-DISTINGUISHER
 0   main
 1   client-a   ether2
 2   client-b   ether3
 3   client-c   ether4
/ip/route print where routing-table=client-a
/ip/route print where routing-table=main
/ping 192.168.1.1 vrf=main
# Результат: timeout (адрес недоступен из main)

/ping 192.168.1.1 vrf=client-a
# Результат: reply (адрес доступен в VRF client-a)
/routing/bgp/session print
/routing/bgp/advertisements print where address-family=vpnv4
/ip/route print where routing-table=client-a type=connected
/ip/vrf print detail
# Проверяем, что интерфейс указан в поле interfaces
/ip/vrf set [find name=client-a] interfaces=ether2
/routing/table add name=client-a fib
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-port=53 protocol=udp action=mark-routing \
    new-routing-mark=main passthrough=yes
/ip/firewall/mangle add chain=prerouting in-interface=ether2 \
    dst-port=53 protocol=tcp action=mark-routing \
    new-routing-mark=main passthrough=yes
# Правильно: отдельные bridge для каждого VRF
/interface/bridge add name=bridge-client-a
/interface/bridge/port add bridge=bridge-client-a interface=ether2
/ip/vrf set [find name=client-a] interfaces=bridge-client-a
/routing/ospf/instance print detail
# Проверяем поля routing-table и vrf
# Все маршруты во всех таблицах
/ip/route print

# Фильтр по конкретной таблице
/ip/route print where routing-table=client-a

# Только active маршруты
/ip/route print where routing-table=client-a active=yes
/interface/print stats where name~"ether[2-4]"
/tool/traceroute 8.8.8.8 vrf=client-a
/ip/arp print where interface=ether2
Routing / VRF на MikroTik — виртуальные таблицы маршрутизации
RouterOS 7.x