Hi,

i have created two different OSPF instances , one is under MAIN routing table , the other one is under a different VRF.

Between the two Mikrotiks there is ethernet cable and two VLANs , one carrying the main OSPF instance and a second vlan carrying the second VRF OSPF instance.

The problem is that the main routing instalce works fine (all attached networks are redistributed to main OSPF instance) but in the second instance running in the VRF, OSPF runs OK , there is designated and backup router but the attached networks are not advertised from one side to the other. It is not a mistake of attached interfaces as the ones i want redistibuted via the VRF OSPF instance do belong the appropriate VRF.

Any ideas?

Thank you

Kolpano

Please paste the following:

/routing ospf instance export
/routing ospf area export
/routing ospf network export

/ip route vrf export

/ip address export

Hi,

thank you for your prompt reply, the topology is simple

mikrotik1---two ospf Instances---mikrotik-2 . The problem is that VR routes attached to mikrotik-1 are not propagated to mikrotik2 and vice versa - this is only true for the vrf instance. The MAIN OSPF instance works OK and routes are learned correctly btw Mikrotik 1 and Mikrotik 2.



Outpout from mikrotik 1

[admin@Mikrotik-1] > /routing ospf instance export
# jan/02/1970 01:14:42 by RouterOS 4.11
# software id = ZYYS-TIN6
#
/routing ospf instance
set OSPF-MAIN comment="" disabled=no distribute-default=never in-filter=\
ospf-in metric-bgp=auto metric-connected=20 metric-default=1 \
metric-other-ospf=auto metric-rip=20 metric-static=20 name=OSPF-MAIN \
out-filter=ospf-out redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=172.20.95.2
add comment="" disabled=no distribute-default=never in-filter=ospf-in \
metric-bgp=auto metric-connected=20 metric-default=1 metric-other-ospf=\
auto metric-rip=20 metric-static=20 name=OSPF-VRF out-filter=ospf-out \
redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=10.20.95.2 routing-table=vrf


[admin@Mikrotik-1] > /routing ospf area export
# jan/02/1970 01:15:06 by RouterOS 4.11
# software id = ZYYS-TIN6
#
/routing ospf area
set backbone-main area-id=0.0.0.0 comment="" disabled=no instance=OSPF-MAIN \
name=backbone-main type=default
add area-id=0.0.0.0 comment="" disabled=no instance=OSPF-VRF name=\
backbone-vrf type=default

[admin@Mikrotik-1] > /routing ospf network export
# jan/02/1970 01:15:25 by RouterOS 4.11
# software id = ZYYS-TIN6
#
/routing ospf network
add area=backbone-main comment="" disabled=no network=172.20.94.0/30
add area=backbone-vrf comment="" disabled=no network=10.20.94.0/30


[admin@Mikrotik-1] > /ip route vrf export
# jan/02/1970 01:15:51 by RouterOS 4.11
# software id = ZYYS-TIN6
#
/ip route vrf
add comment="" disabled=no interfaces=\
vlan-vrf,vlan-vrf-to-client,loopback0-vrf route-distinguisher=1:1 \
routing-mark=vrf


[admin@Mikrotik-1] > /ip address export
# jan/02/1970 01:16:22 by RouterOS 4.11
# software id = ZYYS-TIN6
#
/ip address
add address=172.20.95.2/32 broadcast=172.20.95.2 comment="" disabled=no \
interface=loopback0-main network=172.20.95.2
add address=172.20.94.1/30 broadcast=172.20.94.3 comment="" disabled=no \
interface=vlan-main network=172.20.94.0
add address=172.20.64.1/23 broadcast=172.20.65.255 comment="" disabled=no \
interface=vlan-main-to-client network=172.20.64.0
add address=10.20.64.1/23 broadcast=10.20.65.255 comment="" disabled=no \
interface=vlan-vrf-to-client network=10.20.64.0
add address=10.20.94.1/30 broadcast=10.20.94.3 comment="" disabled=no \
interface=vlan-vrf network=10.20.94.0
add address=10.20.95.2/32 broadcast=10.20.95.2 comment="" disabled=no \
interface=loopback0-vrf network=10.20.95.2


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And output from Mikrotik-2

admin@Mikrotik-2] > /routing ospf instance export
# jan/02/1970 01:17:16 by RouterOS 4.11
# software id = NY53-VHHJ
#
/routing ospf instance
set OSPF-MAIN comment="" disabled=no distribute-default=never in-filter=\
ospf-in metric-bgp=auto metric-connected=20 metric-default=1 \
metric-other-ospf=auto metric-rip=20 metric-static=20 name=OSPF-MAIN \
out-filter=ospf-out redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=172.20.95.1
add comment="" disabled=no distribute-default=never in-filter=ospf-in \
metric-bgp=auto metric-connected=20 metric-default=1 metric-other-ospf=\
auto metric-rip=20 metric-static=20 name=OSPF-VRF out-filter=ospf-out \
redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=10.20.95.1 routing-table=vrf


[admin@Mikrotik-2] > /routing ospf area export
# jan/02/1970 01:17:48 by RouterOS 4.11
# software id = NY53-VHHJ
#
/routing ospf area
set backbone-main area-id=0.0.0.0 comment="" disabled=no instance=OSPF-MAIN \
name=backbone-main type=default
add area-id=0.0.0.0 comment="" disabled=no instance=OSPF-VRF name=\
backbone-vrf type=default

[admin@Mikrotik-2] > /routing ospf network export
# jan/02/1970 01:18:08 by RouterOS 4.11
# software id = NY53-VHHJ
#
/routing ospf network
add area=backbone-main comment="" disabled=no network=172.20.94.0/30
add area=backbone-vrf comment="" disabled=no network=10.20.94.0/30


[admin@Mikrotik-2] > /ip route vrf export
# jan/02/1970 01:18:29 by RouterOS 4.11
# software id = NY53-VHHJ
#
/ip route vrf
add comment="" disabled=no interfaces=vlan-vrf,loopback0-vrf,ether3 \
route-distinguisher=1:1 routing-mark=vrf

[admin@Mikrotik-2] > /ip address export
# jan/02/1970 01:18:52 by RouterOS 4.11
# software id = NY53-VHHJ
#
/ip address
add address=172.20.95.1/32 broadcast=172.20.95.1 comment="" disabled=no \
interface=loopback0-main network=172.20.95.1
add address=192.168.70.226/27 broadcast=192.168.70.255 comment="" disabled=no \
interface=ether3 network=192.168.70.224
add address=172.20.94.2/30 broadcast=172.20.94.3 comment="" disabled=no \
interface=vlan-main network=172.20.94.0
add address=10.20.94.2/30 broadcast=10.20.94.3 comment="" disabled=no \
interface=vlan-vrf network=10.20.94.0
add address=10.20.95.1/32 broadcast=10.20.95.1 comment="" disabled=no \
interface=loopback0-vrf network=10.20.95.1


Thank you

Kolpano

I'm not sure this functionality works. There was another user who posted a few months back with the same issue. http://forum.mikrotik.com/viewtopic.php?f=14&t=43975

I can confirm redistribute-static and redistribute-connected work when using BGP as the routing protocol; /routing bgp instance vrf. I'll setup a test environment to try and redistribute connected routes via OSPF, but for now this is the only input I can offer.

Hi Blake, thank you for your answer.

in the post you mentioned there is an answer from azg that this VRF & OSPF & redistribution of static routes works.

I would be happy if you have the time to setup a lab and see if it works.


Kolpano

i use a single OSPF instance in a VRF on most routers i have. however i don't use redistribution of connected routes: instead, my network statements cover all local networks. that way OSPF adds dynamic interfaces based on the settings in the "all" interface (for all interfaces that don't already have explicit OSPF ettings). the "all" interface should be marked passive.
as a result OSPF distributes the routed from first-hand knowledge because it knows about the interface, which then works in VRFs as well.

FYI i had difficulties with OSPF when interfaces were changed quickly in winbox, e.g. when you copy a dynamically generated interface to make changes to it & then save it as an static one. OSPF then stopped sending HELLO packets. try making only one change at a time & give it 2-3 seconds before making the next change. other people have had issues with OSPF when the interface changed state quickly (which may be similar to stressing it via winbox). for me OSPF was stable except for the missing HELLO. does anyone know is this is fixed in 4.13? i run 4.13 but it is too new to tell.

andy

Thanks Azg.

The strange thing is the redistribution works fine with the MAIN OSPF instance. However redistribution does not work with the VRF OSPF instance. This may not be normal behaviour (probably a bug?)

I will try the dynamic OSPF nature and let you know.

Kolpano.

kolpano, i believe there are two areas on MT routers where you need to test everything you use:

1. anything related to VRFs. make sure you understand not only how your forward traffic is processed, but keep a keen eye on how the packets come back. also remember that the router itself is in the main table, and this includes tunnel source/destination external IPs. also there are some effects that show the VRFs are not entirely separate, and some functionality (DHCP) does not allow you to specify which VRF should be affected -- it goes into the main...

2. source addresses of packets originating from the router are hard to control. most tunnels don't allow to set the src address, frequently leading to surprises once you check on the wire which source IP the router has chosen, and where your packets flow to. same for NTP, and so on. rather than trying to fix this with weird packet mark and mangling rules, it is frequently better to use two routers instead of one.

andy

Hi Andy,

thanks for the info you provided with your previous email.

I tried what you proposed and the results are the following:

1. As far as connected routes are concerned , it works. i added these connected routes in the appropriate area of the VRF instance (and added also the interface as passive) , and these routes were learned to the other side.

2. However i have around 100 static routes "behind" connected interfaces and i can not imagine a way of doing this static redistribution .

Everything is easy in the main ospf instance (redistribution of connected and static works fine) , all the problems are with the VRF instance

Thanks

Kolpano

Hi to all,

I tried RIP instead of OSPF in the VRF instance and everything works OK , redistribution and static routes propagate correctly with RIP. So the problem is only with OSPF at the VRF instance.

i use redistribution of static routes into OSPF, all within a VRF. (the discussion so far was about connected routes).
are the routes you want to redistribute in the same VRF as the OSPF instance that should see them?

Hi Andy,

yes the static routes are in the same OSPF VRF instance. Although i see that there are LSAs for these routes , they do not appear in the OSPF routing table.

Thanks

Kolpano

well, the OSPF instance IS redistributing your static routes then.

it's merely a network / OSPF configuration issue then.
are the destination IPs in question (those behind the static route entries) reachable from other OSPF routers in your network?
if yes then OSPF simply found a better path to them.

otherwise, for reasons why a LSA does not lead to a route being installed:
http://www.cisco.com/en/US/tech/tk365/t ... 481a.shtml
there are other documents on the web as well --

andy

Hi Andy,

the strange thing is that i run two OSPF instances which are identical in the same two mikrotiks , one is running within the General Routing Table and the other is running in the VRF. The general OSPF instance runs correctly but the VRF does not redistribute static and connected routes. They run in the same boxes , everything is identical , the general process runs correctly but the VRF does not.

If it was a network/ospf configuration issue , then the general ospf instance would have the same problem also.

Kolpano

well that is a top level view, yes. but obviously something is not as you expect it, so there probably is something in the details not as identical as you'd expect. you really have to dig into the details to find an issue:
- you write there is an LSA for your static routes, so OSPF *IS* redistributing your static routes. correct?
- from a different OSPF router in your network: the destination IPs, are they reachable? is there an LSA?

Hi Andy,

>you write there is an LSA for your static routes, so OSPF *IS* redistributing your static routes. correct?

Yes correct there exists an LSA for every static route.

>from a different OSPF router in your network: the destination IPs, are they reachable? is there an LSA?

Actually there are only two Mikrotiks

NET-10.20.64.0/23-----Connected-to---Mikrotik-1<<<-------->>>>Mikrotik-2---Connected-to-192.168.70.x-NET

There is also a static route behind the 10.20.64.1 interface of Mikrotik 1.

The result is that i have LSAs for all these networks but not routes. For example Mikrotik-2 has an LSA for 10.20.64.0 but no ospf route is installed.

Please note that if i run RIPv2 for the same VRF instance everything works fine. Also i run the above scenario in the MAIN OSPF instance it runs correctly so i believe that this is a VRF OSPF issue.

I believe that the problem is the same that TRM3 described in the thread viewtopic.php?f=14&t=43975

Is there a way this thread to have proper attention from Mikrotik "routing" engineers ?

Thanks again

Kolpano

i don't know if you still care as you have RIP working, but to be able to see the exact details of your setup, you'd need to post the actual configuration: interface addresses, static routes, ospf instances, ospf interfaces. as it is a small setup it should be reasonably easy to find the problem. i still think you have an OSPF misconfiguration, as in my networks i do use redistribution of static routes from VRFs (its actually something fairly important).

i think you get all the attention in this forum from MT support and engineering - on top of that this forum seems to be the inofficial change log and inofficial bug tracker : )

andy

Hi Andy,

RIP is working but it wold be better to have OSPF VRF working

The topology is very simple:

10.20.64.0/23--Connected-to---Mikrotik-1 (10.20.94.1) <<<----OSPF-VRF---->>>Mikrotik-2 (10.20.94.2)----Connected-to-192.168.70.x

There is also a static route in Mikrotik 1 pointing to network 192.168.64.0/30 via the 10.20.64.0/23 net.

To make the topology even simpler i have removed the MAIN OSPF instance and the problem of not redistributing either connected or static continues.

Both routers run on area 0.0.0.0 and the network between them is 10.20.94.0 (MTK 1 is 10.20.94.1 and MTK-2 is 10.20.94.2)

Loopback interfaces are 10.20.95.1 for MTK-2 and 10.20.95.1 for MTK-2

Config of MTK 1

/routing ospf instance
add comment="" disabled=no distribute-default=never in-filter=ospf-in \
metric-bgp=auto metric-connected=20 metric-default=1 metric-other-ospf=\
auto metric-rip=20 metric-static=20 name=ospf-vrf out-filter=ospf-out \
redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=10.20.95.2 routing-table=vrf
[admin@Mikrotik-1] >
[admin@Mikrotik-1] >
[admin@Mikrotik-1] > /routing ospf area export
# jan/02/1970 00:43:19 by RouterOS 4.12
# software id = ZYYS-TIN6
#
/routing ospf area
add area-id=0.0.0.0 comment="" disabled=no instance=ospf-vrf name=area-vrf \
type=default

[admin@Mikrotik-1] > /routing ospf network export
# jan/02/1970 00:43:32 by RouterOS 4.12
# software id = ZYYS-TIN6
#
/routing ospf network
add area=area-vrf comment="" disabled=no network=10.20.94.0/30
[admin@Mikrotik-1] >
[admin@Mikrotik-1] > /ip route vrf export
# jan/02/1970 00:43:47 by RouterOS 4.12
# software id = ZYYS-TIN6
#
/ip route vrf
add comment="" disabled=no interfaces=\
vlan-vrf,vlan-vrf-to-client,loopback0-vrf route-distinguisher=1:1 \
routing-mark=vrf


[admin@Mikrotik-1] > /ip address export
# jan/02/1970 00:52:55 by RouterOS 4.12
# software id = ZYYS-TIN6
#
/ip address
add address=10.20.64.1/23 broadcast=10.20.65.255 comment="" disabled=no \
interface=vlan-vrf-to-client network=10.20.64.0
add address=10.20.94.1/30 broadcast=10.20.94.3 comment="" disabled=no \
interface=vlan-vrf network=10.20.94.0
add address=10.20.95.2/32 broadcast=10.20.95.2 comment="" disabled=no \
interface=loopback0-vrf network=10.20.95.2


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


AND for MTK-2

[admin@Mikrotik-2] > /routing ospf instance export
# jan/02/1970 00:53:52 by RouterOS 4.12
# software id = NY53-VHHJ
#
/routing ospf instance
add comment="" disabled=no distribute-default=never in-filter=ospf-in \
metric-bgp=auto metric-connected=20 metric-default=1 metric-other-ospf=\
auto metric-rip=20 metric-static=20 name=ospf-vrf out-filter=ospf-out \
redistribute-bgp=no redistribute-connected=as-type-1 \
redistribute-other-ospf=no redistribute-rip=no redistribute-static=\
as-type-2 router-id=10.20.95.1 routing-table=vrf

[admin@Mikrotik-2] > /routing ospf area export
# jan/02/1970 00:54:15 by RouterOS 4.12
# software id = NY53-VHHJ
#
/routing ospf area
add area-id=0.0.0.0 comment="" disabled=no instance=ospf-vrf name=area-vrf \
type=default


[admin@Mikrotik-2] > /routing ospf network export
# jan/02/1970 00:54:47 by RouterOS 4.12
# software id = NY53-VHHJ
#
/routing ospf network
add area=area-vrf comment="" disabled=no network=10.20.94.0/30


[admin@Mikrotik-2] > /ip route vrf export
# jan/02/1970 00:55:19 by RouterOS 4.12
# software id = NY53-VHHJ
#
/ip route vrf
add comment="" disabled=no interfaces=vlan-vrf,loopback0-vrf,ether3 \
route-distinguisher=1:1 routing-mark=vrf


[admin@Mikrotik-2] > ip address export
# jan/02/1970 00:56:09 by RouterOS 4.12
# software id = NY53-VHHJ
#
/ip address
add address=192.168.70.226/27 broadcast=192.168.70.255 comment="" disabled=no \
interface=ether3 network=192.168.70.224
add address=10.20.95.1/32 broadcast=10.20.95.1 comment="" disabled=no \
interface=loopback0-vrf network=10.20.95.1
add address=10.20.94.2/30 broadcast=10.20.94.3 comment="" disabled=no \
interface=vlan-vrf network=10.20.94.0


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


As you can see from the following

[admin@Mikrotik-1] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 10.20.64.0/23 10.20.64.1 vlan-vrf-to-client 0
1 ADC 10.20.94.0/30 10.20.94.1 vlan-vrf 0
2 ADC 10.20.95.2/32 10.20.95.2 loopback0-vrf 0
3 A S 192.168.64.0/30 10.20.64.2 1

MTK-1 has not learned routes from MTK-2 (if everything worked correclty then MKT-1 should know 192.168.70.224)

But LSAs do exist :

admin@Mikrotik-1] > routing ospf lsa print
AREA TYPE ID ORIGINATOR SEQUENCE-NU... AGE
area-vrf router 10.20.95.1 10.20.95.1 0x80000004 798
area-vrf router 10.20.95.2 10.20.95.2 0x80000004 800
area-vrf network 10.20.94.1 10.20.95.2 0x80000002 800
external as-external 10.20.64.0 10.20.95.2 0x80000002 839
external as-external 10.20.95.1 10.20.95.1 0x80000002 850 <---FROM MTK-2
external as-external 10.20.95.2 10.20.95.2 0x80000002 839
external as-external 192.168.64.0 10.20.95.2 0x80000002 839
external as-external 192.168.70.224 10.20.95.1 0x80000002 850 <-----LSA FROM MTK-2

Finally from the routing table of MTK-2 :

admin@Mikrotik-2] > ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADC 10.20.94.0/30 10.20.94.2 vlan-vrf 0
1 ADC 10.20.95.1/32 10.20.95.1 loopback0-vrf 0
2 ADC 192.168.70.224/27 192.168.70.226 ether3 0

No routes from MKT-1 are learned to MTK-2 (192.168.64.0/30 and 10.20.64.0/23) although the LSAs are there:

[admin@Mikrotik-2] > routing ospf lsa print
AREA TYPE ID ORIGINATOR SEQUENCE-NU... AGE
area-vrf router 10.20.95.1 10.20.95.1 0x80000004 652
area-vrf router 10.20.95.2 10.20.95.2 0x80000004 655
area-vrf network 10.20.94.1 10.20.95.2 0x80000002 655
external as-external 10.20.64.0 10.20.95.2 0x80000002 694 <-------- FROM MTK-1
external as-external 10.20.95.1 10.20.95.1 0x80000002 704
external as-external 10.20.95.2 10.20.95.2 0x80000002 694 <--- FROM MTK-1
external as-external 192.168.64.0 10.20.95.2 0x80000002 694 <------ FROM MTK-1
external as-external 192.168.70.224 10.20.95.1 0x80000002 704

If i switch to MAIN OSPF or RIP-VRF everything works correctly.

Once again thank you for your help,

Kolpano

Hi Andy,

in order to better troubleshoot the VRF redistribution issue, is it possible to provide me with a sample of a working config with two routers? Probably something is not right with import/export rules although i tried various configs.

Thanks

Kolpano.

give me 1-2 days to replicate your config. i'm getting a couple RB750G tomorrow & will try to re-create your setup - andy

thnks

kolpano, i can confirm your findings: OSPF redistribution of connected and static routes does not work for OSPF instances within a VRF (more precise mechanism given below, the issue is on the receiving side). this happens in a small test network similar to yours & it also happens on our production network, this now explains some suboptimal link loads... i verified with 4.13 & also downgraded to 4.10 to test -- same result.

the issue seems to be related to the DN bit in LSAs:

the DN bit is defined in RFC4576 -- in short, it is used to prevent "that routes learned from a particular BGP domain are [] redistributed back into that BGP domain" in a BGP/MPLS IP VPN scenario. it seems to be a cisco invention (or should we call it a hack?)

MT OSPF within VRFs send LSAs for connected/static routes, with DN set.
MT OSPF in the main table sends the same LSAs without DN set.

on the receiving side then, if a MT OSPF instance is within a VRF, it ignores LSAs with DN set. this is the case you describe.
MT OSPF in the main table however does install routes with DN set. that is why we on some routers in our network we see the redistributed static routes... it is those routers that do not use VRFs i.e. have OSPF work on the main table.

the document http://www.cisco.com/en/US/docs/ios/12_ ... fvrfl.html
states that "The concept of VRFs can be used on a router that is not a PE router (that is, a router that is not running BGP). With the capability vrf-lite command, the checks can be turned off to allow correct population of the VRF routing table with routes to IP prefixes."

this is our case: VRFs used without BGP.
and the "capability vrf-lite" command is what we would need -- it effectively disables the effect of the DN bit i understand.

i have found nothing on MT 4.13 that would allow to fix this situation. with route filters the DN bit can not be influenced.
mrz... given that you have your own ospf code, this should be a farily easy one to fix????

andy

Thanks a lot Andy for confirming that.

I really appreciate the fact that you setup a lab to confirm my findings. Karma for you!

i am really stack now as i need to run ospf in vrf for a customer.

Mrz is there a possibility to have a solution on that and how soon?

Thank you

Kolpano.

summarized:
- OSPF does not work from VRFs with no MPLS.
- the problem is debugged and documented above.
- the required change would be small -- different interpretation of a single bit (DN).

looks like there is no interest....
kolpano, do you have an open ticket for this? have you formally updated them?
andy

Hello! Resolved?

hi.
any news?

problem not resolved.
sad =(

may be in 6x this problem fixed?

http://wiki.mikrotik.com/wiki/Manual:RouterOS6_news
state
"New OSPF parameter use-dn. Forces to ignore DN bit in LSAs. "

the parametes does not show in winbox. but is configureable via cli.
with use-dn=no i can propagate connected and static routes on ospf instance on a vrf on a vlan without mpls.

can others please confirm ?

sep

http://wiki.mikrotik.com/wiki/Manual:RouterOS6_news
state
"New OSPF parameter use-dn. Forces to ignore DN bit in LSAs. "

the parametes does not show in winbox. but is configureable via cli.
with use-dn=no i can propagate connected and static routes on ospf instance on a vrf on a vlan without mpls.

can others please confirm ?

sep

I can confirm. Setting this option and then bouncing the associated instance works.

There was a similar problem And it works. Long tormented. Thank you.