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 оборудования и так функционал выше среднего.
FYI, Микротиковцы сказали, что про эту “фичу” знают и полноценный VRF ожидается в Routeros 7.
Посмотрим когда выйдет routeros 7. Объём работ, чтобы перейти с обычных rt на netns очень большой для них
Можно ли сделать подмену IP-адреса для IPSec VPN туннеля?
ну туннель на микротик на сеть 172.27.88.0/24 а через VRF преобразуется в 192.168.88.0/24 (локалка микротика)
типа 172.27.88.4 -> 192.168.88.4
Pingback: Основы статической маршрутизации в Mikrotik RouterOS — iT ОБОЗРЕВАТЕЛЬ
Pingback: Основы статической маршрутизации в Mikrotik RouterOS – CHEPA website
Pingback: Основы статической маршрутизации в Mikrotik RouterOS - Дорвеи и Сателлиты