OSPF + MPLS.

Hi all,

I have 50 routers running ROS and I’m starting an implementation of OSPF and MPLS protocols.
The problem is:

If I use ROS 4.x, the OSPF Virtual Links do not work, the default route in the end devices is not installed properly.
This issue has been reported to the Mikrotik Support Team and I was informed that is a bug.
Ok, based on this report, I downgrade the routers to the 3.30 legacy and the OSPF works fine BUT to use mpls-test package in 3.30 I had to install routing-test package and the problem in the OSPF happened again!

How to use OSPF+MPLS with multi-area in ROS?
Thanks!

PS: Sorry for my english. =)

You can simply ditch virtual link and redesign that part of the network where virtual link is used.

Or as a temporary workaround until bug is fixed, instead of virtual link connect that area to backbone with EoIP tunnel.

Virtual Link is an OSPF’s very important feature. The bug should have been corrected in 4.17 release.
We have to stop the deployment.

Thanks.

Hi,

Can anyone explain to me how to use EoIP tunnels in place of OSPF Virtual Links?

Thanks!

Make EoIP tunnel between 2 loopback ip addresses.
Remember to have unique eoip id in your network.

EoIP is very simple…
Look this example and try
http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP

regards.

Hi jalokim, thank you for de reply.
My situation is figured in the image attached and works fine on ROS 3.30 (no virtual link bug) but not in 4.x/5.x.
How can I use EoIP tunnels in place of virtual links in this topology?

192.168.0.0/30 → Area0
10.255.255.1 (lo) → Area0
192.168.4.0/30 → Area1
10.255.255.2 (lo) → Area1
10.255.255.3 (lo) → Area1
10.0.0.0/24 → (Area2) to summary from NAS R3.

Thanks!
OSPF Virtual link.png

(yeah, old, but Google searches lead here so it’s worth answering the question)

I assume you’re using the virtual link to allow Area 2 to be adjacent to OSPF backbone area 0, correct?

Make sure R2 and R3 can ping each other at their loopback IPs, via Area1.

Create EoIP tunnel endpoints on R2 and R3, each targeting the other’s loopback IPs and give the tunnel an identifier unique among all EoIP tunnels on your network, as discussed above. Also make sure you’ve got 28 bytes of MTU overhead available to you throughout Area1.

This creates a new “EoIP” interface on R2 and on R3, which if configured properly acts like a long wire run between the two routers, where all layer 2 traffic you feed in one end comes pristinely out the other. Configure R2’s EoIP interface to participate in OSPF Area 0, and you’re done.

Virtual Link is an OSPF’s very important feature. The bug should have been corrected in 4.17 release.
We have to stop the deployment.


Patent tescili

Hey, I’m not saying it’s not. Just clarifying the workaround someone else suggested to get previous poster, or anyone else who googles and finds the thread who may be in a similar enough boat, through the day. :smiley: