+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Играюсь с VRF — что я делаю не так?

Играюсь с VRF — что я делаю не так?, RouterOS

mtest001

Guest

06.08.2024 09:04:00

Всем привет! Сейчас провожу эксперименты с VRF, чтобы реализовать автоматический failover между двумя провайдерами, и в целом всё работает, но есть несколько странных моментов, по которым я буду признателен за помощь. Контекст такой: у меня два провайдера. У роутеров от обоих провайдеров одинаковый IP — 192.168.1.1. Моя LAN сеть тоже 192.168.1.0/24. Так как вся сеть в одной подсети, я поместил каждый роутер провайдера в отдельный VRF:

IP адрес моста — 192.168.1.201
Роутер первого провайдера подключён к ether1, ether1 имеет IP 192.168.1.202 и подключён к своему VRF
Роутер второго провайдера подключён к ether2, ether2 имеет IP 192.168.1.203 и подключён к другому VRF

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

В целом работает, НО есть такие проблемы:
— Интернет из LAN доступен только если IP-адреса Mikrotik в двух VRF назначены с маской /32 — а так быть не должно.
— Если назначать /24, то из консоли Mikrotik можно пинговать google, а из LAN — нет.
— Обновления с Mikrotik не работают, разрешение DNS не происходит.

Ниже мой конфиг, я убрал часть с netwatch, т.к. пока это не суть проблемы:

# model = RB3011UiAS
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip vrf
add comment=vrf_starlink interfaces=ether2 name=vrf_starlink
add comment=vrf_orange interfaces=ether1 name=vrf_orange
/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=ether2 list=WAN
/ip address
add address=192.168.1.201/24 comment=defconf interface=bridge network=192.168.1.0
add address=192.168.1.202 comment=ip_vrf_orange interface=ether1 network=192.168.1.1
add address=192.168.1.203 comment=ip_vrf_starlink interface=ether2 network=192.168.1.1
/ip dns
set allow-remote-requests=yes servers=9.9.9.9
/ip dns static
add address=192.168.1.201 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/ip route
add disabled=no distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf_orange routing-table=main suppress-hw-offload=no
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf_starlink routing-table=main suppress-hw-offload=no
add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=bridge routing-table=vrf_orange suppress-hw-offload=no
add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=bridge routing-table=vrf_starlink suppress-hw-offload=no
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf_starlink routing-table=vrf_starlink suppress-hw-offload=no
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf_orange routing-table=vrf_orange suppress-hw-offload=no
/system identity
set name=rb3011

Спасибо всем за помощь!

aleab

Guest

17.09.2024 14:32:00

Привет, я тоже пытаюсь использовать VRF, но у меня похожая проблема. Для теста я использую свою лабораторию, у меня 3 разные подсети: LAN = 192.168.88.0/24, WAN1 (VRF1) = 10.1.1.0/24, WAN2 (VRF2) = 192.168.89.0/24. Прикрепляю rsc. Сейчас я настроил DHCP-сервер с DNS-серверами 8.8.8.8 и 1.1.1.1, потому что если поставить 192.168.88.1 — не работает. Все клиенты в LAN работают нормально, NAT тоже работает, netwatch работает без проблем. Потом настрою правило, чтобы отключить mangle или поменять distance.

Моя единственная проблема — сам роутер не может разрешать имена… Если пытаюсь пинговать IP — работает:

[admin@MikroTik] > ping 1.1.1.1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 57 10ms895us
1 1.1.1.1 56 57 10ms422us
sent=2 received=2 packet-loss=0% min-rtt=10ms422us avg-rtt=10ms658us max-rtt=10ms895us

Если указать VRF/ether — тоже работает:

[admin@MikroTik] > ping 1.1.1.1 vrf=vrf1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 57 10ms831us
1 1.1.1.1 56 57 9ms938us
sent=2 received=2 packet-loss=0% min-rtt=9ms938us avg-rtt=10ms384us max-rtt=10ms831us

[admin@MikroTik] > ping 1.1.1.1 vrf=vrf2
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 54 41ms812us
1 1.1.1.1 56 54 56ms234us
sent=2 received=2 packet-loss=0% min-rtt=41ms812us avg-rtt=49ms23us max-rtt=56ms234us

Но если пытаюсь разрешить имена — не работает:

[admin@MikroTik] > ping www.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: could not get answer from dns server

Конечно, обновить пакеты не могу... Пробовал и с последними правилами mangle, и без них — результат один, проблема именно с DNS на MikroTik. Пробовал телнет с MikroTik — не подключается... Можете помочь? Спасибо!

export.rsc (6.52 KB)

spippan

Guest

17.09.2024 14:49:00

Пытался разобраться с этим и никак не могу понять, как принимается решение о маршрутизации в такой схеме? Пакет с «LAN» (src 192.168.1.x) уходит в «WAN» (либо VRF «starlink», либо «orange»)… Как тогда будет выглядеть обратный путь, если всё в сети 192.168.1.0/24? Я понимаю, что VRF нужны для решения проблемы пересечения IP-адресов, но всё равно не могу понять, как роутер определяет обратный путь из WAN обратно в нужный VRF?

jaclaz

Guest

18.09.2024 08:57:00

@aleab Проблема, с которой ты столкнулся, известна. Пока (похоже, что над этим работают) поддержки DNS в vrf нет. У меня похожая конфигурация, но я «перевернул» vrf, поставив её на стороне LAN, чтобы интерфейсы на стороне WAN были в «main», и тогда DNS работает нормально. Смотри эту ветку: http://forum.mikrotik.com/t/attempting-to-evolve-from-cavemans-failover/170048/59 начиная отсюда (простые vrf): http://forum.mikrotik.com/t/attempting-to-evolve-from-cavemans-failover/170048/59 и до сюда (конфигурация «перевернутого» vrf): http://forum.mikrotik.com/t/attempting-to-evolve-from-cavemans-failover/170048/59

@spippan Посмотри те же ссылки выше, это работает, но мы (по крайней мере я) толком не знаем почему. Главное — чтобы статические маршруты к модемам провайдера были с маской /32 и чтобы возвращающие маршруты были добавлены в таблицы vrf. В «main» возвращающий маршрут (со стороны LAN) добавляется автоматически (он появляется как DAC в выводе /ip route print).

aleab Guest	#5 0 18.09.2024 11:07:00 Хорошо, спасибо. Сейчас читаю твою ссылку. Большое спасибо!!!

spippan Guest	#6 0 18.09.2024 14:45:00 Спасибо, @jaclaz, я с этим разберусь... Интересно, что там.

Amm0

Guest

18.09.2024 15:27:00

Возможно, я что-то упускаю... Но в чем смысл использовать VRF для автоматического переключения у провайдера? — VRF никак не связаны с «автоматическим переключением». Переключение работает и без VRF, а накладывать VRF поверх механизмов переключения — значит только усложнять настройку.

spippan Guest	#8 0 18.09.2024 15:37:00 Все адресные пространства в этой конфигурации находятся в диапазоне 192.168.1.x, согласно автору.

jaclaz

Guest

18.09.2024 15:47:00

Суть в том, что у нескольких роутеров провайдера задан одинаковый IP-адрес (обычно 192.168.1.1), который нельзя изменить (либо потому, что сами роутеры недоступны, либо потому, что на некоторых устройствах в сети в качестве шлюза стоит 192.168.1.1, его тоже нельзя поменять или чтобы изменить – нужно ждать несколько часов или дней, пока не сделают вмешательство удалённо или на месте, которое может быть как бесплатным, так и платным). В моём конкретном случае (и в моей простоте, как у пещерного человека, но пытающегося развиваться) я сейчас использую Ax Lite как «прозрачное устройство», то есть с IP 192.168.1.1 на LAN-порту, которое подключается к другим устройствам (роутерам провайдеров), у которых тоже 192.168.1.1, при этом оно даёт функцию аварийного переключения, но его можно обойти в любой момент, просто вынув Ethernet-кабель, идущий от свича/сети, из LAN-порта Ax Lite и воткнув напрямую в LAN-порт выбранного роутера.

Для протокола: у меня есть побочный проект – альтернативная настройка с тремя портами, которые подключаются к трём модемам провайдеров и объединены в мост с сетью, при этом два из трёх портов отключены или временно исключены из моста. Когда интернет не работает, я могу отключить/удалить текущий порт «к модему» и включить/добавить другой. Для своевременного обновления MAC-адреса устройства с IP 192.168.1.1 требуется «бесполезный» ARP-запрос. Вручную это работает, но я всё ещё не нашёл времени, чтобы получше разобраться в синтаксисе скриптов и написать (пусть хоть и полусырой) рабочий скрипт для автоматизации аварийного переключения.

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

Amm0

Guest

#10

18.09.2024 16:18:00

Конечно, у VRF есть свои случаи применения. Просто хотел сказать, что наличие нескольких одинаковых подсетей разрешено без VRF.

Теперь это означает, что маршрут по умолчанию 0.0.0.0/0 нужно указывать с квалификатором %, например, gateway=192.168.1.1**%etherX-toWAN-Y**. Переключение на резерв происходит с помощью check-gateway=ping (или более сложных подходов с netwatch/рекурсивной маршрутизацией) на основном маршруте с distance=1. Резервный маршрут получает distance=2. То, что подсети одинаковые, не должно быть проблемой для WAN-сети, но необходимо указание интерфейса через %, которое должен автоматически добавлять DHCP-клиент.

jaclaz

Guest

#11

18.09.2024 17:10:00

Если LAN-сеть тоже находится в диапазоне 192.168.1.x/24? Вот здесь у меня всегда получаются проблемы с правильным ответом. Я всегда думал (хотя могу сильно ошибаться), что если интерфейс LAN — 192.168.1.x/24, то другой(ие) интерфейс(ы) могут быть либо в том же диапазоне 192.168.1.x/24, тогда устройство нужно настроить как мост/свитч, либо в другом диапазоне, тогда устройство надо настроить как роутер. Если у вас есть время и желание, не могли бы вы привести более полный пример?

Amm0 Guest	#12 0 18.09.2024 18:21:00 В общем, обычно можно выбрать свою подсеть на стороне LAN так, чтобы избежать конфликтов (дальше) и не заморачиваться с этими эзотерическими вопросами RouterOS… Но давайте предположим, что LAN категорически должен быть 192.168.1.1, и при этом оба WAN тоже обязаны быть 192.168.1.1… Насколько я знаю, это тоже должно работать без VRF. Проблемы могут возникнуть только с фаерволом… в целом любые IP-матчеры (где бы они ни были — фильтр, мангл, NAT, адрес-листы) всегда требуют указания совпадения по какому-то интерфейсу, потому что одного IP не достаточно, чтобы однозначно определить правило. Если говорить на примере, я больше сторонник чистой работы на уровне L3, когда каждая подсеть уникальна и всё маршрутизируется по большой сети. Если это невозможно, можно применить action “netmap” в NAT, который по сути меняет отображение части сети 192.168.1.0/24 — но это полезно только если уже есть какая-то маршрутизируемая мультисайтовая L3-архитектура. То есть, остальная сеть видит какой-то граничный сегмент с 192.168.1.1 как нечто иное, например 10.x.x.x или 192.x.x.x или 172.a.b.x… Концепция NAT с “netmap” позволяет “переименовать” подсеть вроде 192.168.1.x в 192.168.101.x, чтобы сделать её уникальной. Есть и другие похожие приемы с “netmap” как альтернатива VRF. В общем, есть над чем подумать. Возможно, VRF — это правильное решение, если всё действительно завязано на 192.168.1.0/24, но я стараюсь избегать этого варианта, прежде чем переходить к VRF. И последнее: у автора темы Starlink, так что вопрос номер ноль — почему не использовать bypass-режим, чтобы обойти 192.168.1.0/24 и избежать двойного NAT…

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры