Mikrotik RoS v7.1 OSPF – problem with

Problem

Actually, one of the scenarios with OSPF is the distribution of routing information from one branch to another, and there were no problems in 6. I set up a zone, included a range there, issued by any PtP server, and client addresses flew to all branches. Yes, it is very inconvenient when there are many such routes, they can usually be aggregated and there is no problem. But in 7, the problem is different, either because of a bug, or I am doing something wrong, but the routes for PtP clients are not distributed.

Solution

The solution itself is pretty simple.

You just need to declare a static blackhole route to the subnet of these clients with a large metric and assign static routes to propagate in OSPF. There is almost everything here, you also need to filter the routes so that only the necessary ones are distributed, then there will be a code:

/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 rejectr
    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

For the example above, the network 10.0.2.0/24 is dedicated for L2TP clients, 10.0.28.0/24 is a “trial” network to test the filter’s work and should not be propagated.

The filter logic is as follows: if the route is static, then check it for compliance with the criterion, if not, then discard it.

Let’s look at the routes on a neighboring router:

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

As you can see from the listing above, there are only announced routes and route / 32 to the router itself.