Comments 34
Вы в тех.поддержку по поводу проблемы писали? Они обычно помогают и отвечают. Если это реальная проблема ее лучше пофиксить
Может они при переходе к 7-му ROS поменяли принадлежность таких маршрутов? Документацию, традиционно не читал, но... У redistribte вижу варианты "bgp connected copy dhcp fantasy modem ospf rip static vpn", кроме очевидного "connected" могу предположить "vpn" для вашего случая (для PtP это тоже более-менее логично). Каким типом их показывает /ip/route/print ?
Больше похоже на баг
При добавлении клиента x.x.x.x через винбокс получаем адрес в формате x.x.x.x/32 и маршрут не распространяется, правка адреса не помагает, винbокс упорно добавляет префикс /32
Если добавить клиента через cli, то адрес получаем в нужном формате и всё работает. Правка клиента, добавленного через винбокс, в cli тоже даёт положительный результат
7.1 stable, не такой уж и stable
P.S. а ещё интересное поведение маршрутом, если у вас настроен recursive routing
Перед переходом на 7.1 надо убедиться, что значение target scope больше scope, иначе велик шанс к дальней поездке, если роутер на удаленном объекте.
Про рекурсию - проверю в лабе, у меня куча мест, куда я точно не хочу ехать в ближайшее время.
Там даже по другому у рекурсивки. Как я выяснил эмпирически - у пары маршрутов образующих рекурсивный маршрут должен быть разный target scope. Именно на это ругается. Если target scope разные то target scope дефолтного рекурсивного может быть равный scope маршрута на "проверочный" хост.
Спасибо, давно искал решение этой проблемы.
Простите, я может быть не до конца осознал проблему, но идея с "суммарным" blackhole маршрутом и фильтром пропускаюшим только его, очевидна.
Зачем "мусорить" в соседские RIB/FIB россыпью /32, если можно анонсировать только один "изящный" суммарный маршрут?
Ваше непонимание понятно.
OSPF часто используют как магическую технологию, где прописал очень мало чего и все ок. О суммаризации подобных маршрутов начинают думать только тогда, когда их становится много.
В данном случае вышло так, что эти маршруты были отфильтрованны багом, а те кто никогда не заморачивался на суммаризации - просто столкнуться с проблемой, о решении которой они никогда не думали.
7ка какая-то сырая. У меня на chr дикие просадки пингов даже до роутера если какой-то из клиентов начинает загрузку. На 6ке таких проблем нет. В общем откатил назад небыло времени разбираться. А еще я не понял, если уж поменяли что-то у себя коренным образом в операционке, сделайте скрипт чтоли чтобы сатарые конфиги без проблем переезжали.
А если добавить в redistribute connected?
redistribute=static,ospf - тут только статические маршруты и other ospf
Я все варианты пробовал, маршруты до /32 не раздаются.
Очень похоже на старый баг в Quagga, который я репортил аж ЕМНИП в 2011 году(я не в курсе самописная ли реализация протоколов маршрутизации у Mikrotik или заимствованная) - там тоже /30 работал нормально, а /32 - не раздавался вообще(/31 не проверял).
Починили это дело только в каком-то из свежих релизов FRRouting
Такая же проблема, на тестовом железе решил собрать нашу боевую схему, маршруты не раздаются :( На соседнем роутере только gateway Ptp клиента светиться в маршруте...
После обновления до 7.1.1 пробывали?
После обновления до 7.1.3 пробовали?
Я попробовал на 7.1.2
И заметил такую вещь, если у вас GRE с маской 30, то установка OSPF peer в режим p2p - будет проблема, нескончаемый exchange.
Установка в broadcast или смены ip на настоящий p2p (маска 32) - решает проблему.
Однако есть ещё проблема, то ли она в OSPF то ли IPSec/GRE/L2TP, но линки очень часто переходят в exchange и частично ломают маршрутизацию. Я написал им в поддержку на этот счёт, жду ответа.
Что-то не так вы делаете с VPN+OSPF. Простой стенд в GNS3. 1 сервер + 2 клиента.
Локалки 172.16.х.0/24. Линки VPN по /32 из 10.1.1.0/24
Сервер:
/ip address
add address=172.16.1.1/24 interface=bridge1 network=172.16.1.0
/ip pool
add name=vpn ranges=10.1.1.2-10.1.1.20
/ppp profile
add change-tcp-mss=yes local-address=10.1.1.1 name=profile1 remote-address=vpn use-encryption=yes
/ppp secret
add name=1
add name=2
/routing ospf instance
add name=ospf-instance-1 router-id=1.1.1.1
/routing ospf area
add instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 networks=172.16.1.0/24 passive
add area=ospf-area-1 networks=10.1.1.0/24 type=ptp
Клиенты аналогичны. Отличия в адресах LAN и OSPF RID. Экспорт с r2:
/interface l2tp-client
add connect-to=server.local disabled=no name=l2tp-out1 user=u1
/ip address
add address=172.16.2.1/24 interface=bridge1 network=172.16.2.0
/routing ospf instance
add name=ospf-instance-1 router-id=2.2.2.2
/routing ospf area
add instance=ospf-instance-1 name=ospf-area-1
/routing ospf interface-template
add area=ospf-area-1 networks=172.16.2.0/24
add area=ospf-area-1 networks=10.1.1.0/24 type=ptp
Клиент r2 получает IP 10.1.1.20 на vpn и видит сети соседа включая линковочную vpn:
[admin@r2] > ip ro pr
Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 192.168.10.1 1
D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110
DAc 10.1.1.1/32 l2tp-out1 0
DAo 10.1.1.19/32 10.1.1.1%l2tp-out1 110
DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110
DAc 172.16.2.0/24 bridge1 0
DAo 172.16.3.0/24 10.1.1.1%l2tp-out1 110
DAc 192.168.10.0/24 ether1 0
Клиент r3 получает IP 10.1.1.19 на vpn и видит сети соседа включая линковочную vpn:
[admin@r3] > ip ro pr
Flags: D - DYNAMIC; A - ACTIVE; c, o, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 192.168.10.1 1
D o 10.1.1.1/32 10.1.1.1%l2tp-out1 110
DAc 10.1.1.1/32 l2tp-out1 0
DAo 10.1.1.20/32 10.1.1.1%l2tp-out1 110
DAo 172.16.1.0/24 10.1.1.1%l2tp-out1 110
DAo 172.16.2.0/24 10.1.1.1%l2tp-out1 110
DAc 172.16.3.0/24 bridge1 0
DAc 192.168.10.0/24 ether1 0
Коллеги, идея отправлять OSPFом суммарный маршрут вместо кучи мелких - разумеется, правильная, причем правильная сама по себе, в отвязке от описанного бага. Но почему столь обычную задачу предлагается решать таким слегка извращенным способом? Зачем нам костыль в виде статики и ее редистрибуции, если есть вполне себе стандартный, почти штатный способ анонсировать нужный маршрут сразу в OSPF?
OSPF - это link-state протокол. Он завязан на состояние интерфейсов. Маршруты передаются для тех подсетей, которые нацеплены на интерфейсы, которые мы анонсировали в OSPF и которые подняты в данный момент. Корень зла описанного бага - в том, что RouterOS 6 прекрасно умел самостоятельно анонсировать OSPFy поднятые L2TP Binding интерфейсы (они всегда присутствовали в OSPF во вкладке Interfaces) и а Router OS 7 почему-то разучился это делать. Ну, разучился - значит надо просто сделать свой интерфейс, который всегда будет поднят. Лупбэков у Микрота нету - ну, не беда, сделаем, например, бридж, он тоже всегда в апе. Нацепим на него адрес с подсеткой, соответствующие или перекрывающие наш пул адресов для L2TP (надо только не забыть исключить этот адрес из пула, иначе Микрот его в какой-то момент может выдать клиенту - по хорошему он должен хотя бы пингами проверять, не отвечает ли такой адрес в данный момент, но не знаю, заморачивается ли он этим). После этого осталось анонсировать этот интерфейс вместе с заданной подсеткой в OSPF - и вуаля, нужный маршрут разлетается со свистом.
/interface bridge add name=Loopback_L2TP_clients
/ip address add address=10.0.2.254/24 interface=Loopback_L2TP_clients network=10.0.2.0
/routing ospf interface-template add area=local interfaces=Loopback_L2TP_clients networks=10.0.2.0/24 passive
В случае с бриджем, мы получаем L2 там, где раньше был только L3.
И что в этом страшного? мы же его не привязываем к физическому интерфейсу, так что ethernet фреймов от него в сети не будет. Рассматривайте его как классический цисковский лупбэк, которому вдруг зачем-то дополнительно навесили MAC адрес - да, бессмысленный и бесполезный функционал, но от которого нет никакого вреда.
Техподдержка репорт приняла, обещали в будущих релизах доработать :) Будем посмотреть
"Thank you for the report, we are working on this issue and hopefully it will be fixed before next ROS v7 release.
Māris B. "
Интересно, спустя год с лишним и выходом 7.7 на текущий момент что-то поменялось?
Mikrotik RoS v7.1 OSPF — проблема с /32 адресами PtP клиентов