VRF(L3VPN) в Mikrotik RouterOS реализован с помощью таблиц маршрутизации Linux, однако такой способ построения VRF не является полноценным, это связано с тем, что таблицы policy based routing (ip rule), RT local, arp/nd, firewall остаются общими. Кроме того, 0-ое правило PBR (0: from all lookup local) в старых версиях ядра линукс(<2.6.33) нельзя было удалить, что ограничивало возможность реализовать VRF-ы на базе таблиц маршрутизаций Linux, аналогичные Cisco, Juniper и т.п.

Во что же выливаются все эти нюансы реализации и исторические справки? Если кратко, то VRF в Mikrotik не являются полноценными VRF, а именно не решают полностью проблему пересечения IP-адресов в разных адресных пространствах. В случае, когда IP-адрес принадлежит интерфейсу Mikrotik, то он доступен из всех VRF. Для демонстрации этой проблемы будет использоваться RouterOS x86 6.17 (от 18.07.2014). Схема сети следующая:

Сначала настроим только интерфейсы ether1 и ether2 в mikrotik:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2
/ip address
add address=192.0.2.1/30 interface=ether1 network=192.0.2.0
add address=192.0.2.5/30 interface=ether2 network=192.0.2.4

Проверим как оно выглядит в таблицах маршрутизации микротика:

/ip route print detail where routing-mark=vrf1
 0 ADC  dst-address=192.0.2.0/30 pref-src=192.0.2.1 gateway=ether1 gateway-status=ether1 reachable 
        distance=0 scope=10 routing-mark=vrf1 
/ip route print detail where routing-mark=vrf2
 1 ADC  dst-address=192.0.2.4/30 pref-src=192.0.2.5 gateway=ether2 gateway-status=ether2 reachable 
        distance=0 scope=10 routing-mark=vrf2 

Теперь запустим пинги с CE1:

CE1# ping 192.0.2.1 -c 2 
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.121 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.176 ms

CE1# ping 192.0.2.6 -c 2 
PING 192.0.2.6 (192.0.2.6) 56(84) bytes of data.
--- 192.0.2.6 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

CE1# ping 192.0.2.5 -c 2 
PING 192.0.2.5 (192.0.2.5) 56(84) bytes of data.
64 bytes from 192.0.2.5: icmp_seq=1 ttl=64 time=0.172 ms
64 bytes from 192.0.2.5: icmp_seq=2 ttl=64 time=0.183 ms

Строка 1 – пинг до шлюза, всё ок. Строка 6 – пинг до CE2, которая находится в другом VRF, связности нет, всё правильно. Строка 11 – пинг до шлюза, который находится в другом VRF, связность есть, но её не должно было быть.

Далее, отключим eth2 на микротике и включим eth3:

/ip address
add address=192.0.2.1/30 interface=ether1 network=192.0.2.0
add address=192.0.2.6/30 interface=ether3 network=192.0.2.4
/ip route vrf
add interfaces=ether1,ether3 routing-mark=vrf1

Связность между CE1 и CE3, естественно есть (ведь это 2 устройства в одном VRF)

CE1# ping 192.0.2.5 -c 2 
PING 192.0.2.5 (192.0.2.5) 56(84) bytes of data.
64 bytes from 192.0.2.5: icmp_seq=1 ttl=63 time=0.215 ms
64 bytes from 192.0.2.5: icmp_seq=2 ttl=63 time=0.270 ms

Здесь стоит обратить внимание, что ttl=63, потому что пакет прошёл через маршрутизатор, который вычел 1 из 64. В следующем эксперименте это пригодится.

Наконец, включаем все 3 интерфейса на mikrotik:

/ip address
add address=192.0.2.1/30 interface=ether1 network=192.0.2.0
add address=192.0.2.5/30 interface=ether2 network=192.0.2.4
add address=192.0.2.6/30 interface=ether3 network=192.0.2.4
/ip route vrf
add interfaces=ether1,ether3 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

И запускаем пинги с CE1:

CE1# ping 192.0.2.5 -c 2 
PING 192.0.2.5 (192.0.2.5) 56(84) bytes of data.
64 bytes from 192.0.2.5: icmp_seq=1 ttl=64 time=0.280 ms
64 bytes from 192.0.2.5: icmp_seq=2 ttl=64 time=0.183 ms

Как видно, теперь ttl=64, что означает, что это отвечает сам микротик, а не CE3, как хотелось бы (если запустить снифер на CE3, то, действительно, трафик не приходит на CE3). При этом с CE3 и CE2 недоступны шлюзы:

CE2# ping 192.0.2.5 -c 2
PING 192.0.2.5 (192.0.2.5) 56(84) bytes of data.

--- 192.0.2.5 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

CE3# ping 192.0.2.6 -c 2
PING 192.0.2.6 (192.0.2.6) 56(84) bytes of data.

--- 192.0.2.6 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

Это происходит по причине того, что 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 оборудования и так функционал выше среднего.