Проблема
Собственно один из сценариев с OSPF - распространение маршрутной информации от одного филиала в другой, и в 6-ке проблем не было. Настроил зону, включил туда диапазон выдаваемый любым PtP сервером и адреса клиентов полетели по всем филиалам. Да, очень неудобно, когда таких маршрутов много, их обычно можно агрегировать и проблемы нет. Но в 7-ке проблема в другом, то ли из-за бага, то ли я что-то делаю не так, но маршруты для PtP клиентов не распространяются.
Решение
Само решение довольно простое.
Надо просто объявить static blackhole маршрут до подсети этих клиентов с большой метрикой и назначить в OSPF распространение static маршрутов. Тут почти все, надо еще и отфильтровать маршруты, что-бы распространялись только необходимые, далее будет код:
/ip route
add blackhole disabled=no distance=255 dst-address=10.0.2.0/24 gateway="" pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=255 dst-address=10.0.28.0/24 gateway=172.16.26.129 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
/routing ospf instance
add name=ospf-instance-1 out-filter-chain=ospf-out redistribute=static,ospf router-id=10.0.0.129
/routing ospf area
add instance=ospf-instance-1 name=ospf-area-1
add area-id=10.0.3.0 instance=ospf-instance-1 name=local type=stub
/routing filter rule
add chain=ospf-out disabled=no rule="if ( protocol static ){\r\
\n if( dst==10.0.2.0/24 && dst-len==24 ) { accept }\r\
\n} else {\r\
\n reject\r\
\n}"
/routing ospf area range
add area=local disabled=yes prefix=10.0.2.0/24
/routing ospf interface-template
add area=ospf-area-1 dead-interval=4s hello-interval=1s networks=10.0.0.128/25 type=ptp
add area=local networks=10.0.3.0/24 passive
add area=local networks=10.0.2.0/24 passive prefix-list=10.0.2.0/24 type=ptp
add area=local networks=10.0.28.0/24 passive prefix-list=10.0.28.0/24 type=ptpДля примера выше, сеть 10.0.2.0/24 выделена для L2TP клиентов, 10.0.28.0/24 - "пробная", для проверки работы фильтра и распространятся не должна.
Логика фильтра следующая: если маршрут статичный, то проверить его на соответствие критерию, если нет, то отбросить.
Глянем маршруты на соседнем роутере:
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 172.16.26.129 200
DAc 10.0.0.0/25 bridge-ISP 0
D o 10.0.0.129/32 10.0.0.129%gre-tunnel1 110
DAc 10.0.0.129/32 gre-tunnel1 0
DAo 10.0.2.0/24 10.0.0.129%gre-tunnel1 110
DAo 10.0.2.1/32 10.0.0.129%gre-tunnel1 110
DAo 10.0.3.0/24 10.0.0.129%gre-tunnel1 110
DAc 10.0.4.254/32 <l2tp-ppp1> 0
DAc 10.0.5.0/24 ether3 0
DAc 172.16.26.128/25 ether4 0Как видно из листинга выше, тут есть только анонсированные маршруты и маршрут /32 до самого роутера.
Комментарии (15)
XBOCTOB
18.12.2021 23:38Может они при переходе к 7-му ROS поменяли принадлежность таких маршрутов? Документацию, традиционно не читал, но... У redistribte вижу варианты "bgp connected copy dhcp fantasy modem ospf rip static vpn", кроме очевидного "connected" могу предположить "vpn" для вашего случая (для PtP это тоже более-менее логично). Каким типом их показывает /ip/route/print ?
MagicGTS Автор
19.12.2021 00:31Пробовал все варианты, ни один не работает. В листинге из статьи как раз есть такой интерфейс.
negodzq
19.12.2021 00:32+1Больше похоже на баг
При добавлении клиента 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, иначе велик шанс к дальней поездке, если роутер на удаленном объекте.
MagicGTS Автор
19.12.2021 00:33Про рекурсию - проверю в лабе, у меня куча мест, куда я точно не хочу ехать в ближайшее время.
erazel
20.12.2021 11:55Там даже по другому у рекурсивки. Как я выяснил эмпирически - у пары маршрутов образующих рекурсивный маршрут должен быть разный target scope. Именно на это ругается. Если target scope разные то target scope дефолтного рекурсивного может быть равный scope маршрута на "проверочный" хост.
daWSL
19.12.2021 11:07Простите, я может быть не до конца осознал проблему, но идея с "суммарным" blackhole маршрутом и фильтром пропускаюшим только его, очевидна.
Зачем "мусорить" в соседские RIB/FIB россыпью /32, если можно анонсировать только один "изящный" суммарный маршрут?
MagicGTS Автор
19.12.2021 11:12Ваше непонимание понятно.
OSPF часто используют как магическую технологию, где прописал очень мало чего и все ок. О суммаризации подобных маршрутов начинают думать только тогда, когда их становится много.
В данном случае вышло так, что эти маршруты были отфильтрованны багом, а те кто никогда не заморачивался на суммаризации - просто столкнуться с проблемой, о решении которой они никогда не думали.
sclk34
19.12.2021 13:027ка какая-то сырая. У меня на chr дикие просадки пингов даже до роутера если какой-то из клиентов начинает загрузку. На 6ке таких проблем нет. В общем откатил назад небыло времени разбираться. А еще я не понял, если уж поменяли что-то у себя коренным образом в операционке, сделайте скрипт чтоли чтобы сатарые конфиги без проблем переезжали.
MagicGTS Автор
19.12.2021 15:35Я понимаю почему они не сделали полную автомиграцию - это очень не просто само по себе, да и учесть все нюансы конфигурации и особенности поведения старой версии софта при переносе в новую версию вообще считай невозможно.
pfzr
19.12.2021 14:36А если добавить в redistribute connected?
redistribute=static,ospf - тут только статические маршруты и other ospfMagicGTS Автор
19.12.2021 14:36Я все варианты пробовал, маршруты до /32 не раздаются.
Pinkbyte
19.12.2021 23:40Очень похоже на старый баг в Quagga, который я репортил аж ЕМНИП в 2011 году(я не в курсе самописная ли реализация протоколов маршрутизации у Mikrotik или заимствованная) - там тоже /30 работал нормально, а /32 - не раздавался вообще(/31 не проверял).
Починили это дело только в каком-то из свежих релизов FRRouting
Maxim_Q
Вы в тех.поддержку по поводу проблемы писали? Они обычно помогают и отвечают. Если это реальная проблема ее лучше пофиксить
MagicGTS Автор
Ещё не успел, надо было обходняк сделать.