Bumping this and asking if MPLS has finally gotten stable in V7 by now?
7.17 has some useful features and i’m interested in starting to upgrade segments and turn MPLS back on, but not if its just the same old story of randomly breaking loopbacks and customer routes and having to rip it out again
Still no multicore processing and no hardware offload but works fine if those are not important to you
The speed is not as important as the stability. I believe LDP was the problem and not the MPLS process itself. Labels get stuck or out of sync with the routing table and specific routes become blackholed with invalid labels
My experience (on v6, never ran it on v7) is it would run fine for several weeks then it would happen. Whether thats from a flapping OSPF route i’m not sure, but it was ultimately unreliable and caused major outages as the only way to fix it was to systematically go along the path rebooting routers
If anyones running a 50+ router network with several hundred routes and it’s stable for months on end despite link flaps, i’d like to know
And if you are running LDP and/or MP-BGP instead
I used to run 12 CCR2216 routers with ospf, mpls, ldp, mp-bgp which seemed to run fine for me but only issue I had was the cpu usage on single core was almost 100 or at 100 and all other cores are sitting at almost 0.
Ok just had this happen again on a router running 7.17.2
Didn’t even know I had MPLS running on it or its neighbours but sure enough broken labels causing an unreachable neighbouring router. However routes behind it - customer traffic - were fine. Re-establishing OSPF or rebooting the neighbour doesn’t work
Had to disable LDP in order to reach the neighbor
So MPLS or at least LDP is still broken to this day
This is the precise reason why we moved to other vendor, because no solution in plain sight for some features that we need as SP, best of luck to MT specially now they are doing EVPN which will open another set of can of worms (I hope for the better) this MPLS stuff for sure will going to push back to back burner, I hope this is not the intention of MT to remove MPLS in the code base and replace it with EVPN+VXLAN stuff, proved us wrong MikroTik
1 Like
- VPN4 broken also. not possible to export static default to vpn4 network.
- transit traffic over static routes from VPN4 appear in SNAT but not appear on DNAT and not appear in mangle prerouting . but appear in postrouting.
- static routes which are recursive not exportable
most important and preferred feature for Mikrtoik is docker container support.
If you’re using MPLS as a P router or in a PE role with VPLS, it’s generally pretty stable now even in ROSv6/ROSv7 interop. Most of the issues with MPLS that still exist center around L3VPN and throughput/resource utilization.
One thing that most people miss in a MikroTik MPLS network is matching the timers for IGP/LDP since there is no LDP/IGP synchronization feature. Making sure that LDP timers and OSPF/IS-IS timers match is a big part of running a stable MikroTik network. It helps to ensure that routes don’t get stuck in the mpls forwarding table when the IGP routing table has changed.
Also, applying input/output filters to limit the LDP prefixes that exist is important, especially in bigger networks.
VPLS Performance is much better but still a work in progress as they optimize the ability to use multiple CPU cores. HW Offload would also make a huge difference.
1 Like
I really hope MPLS is not abandoned as it is still the primary technology used in Service Provider networks, and I can’t see that changing.
I would hope not, VxLAN as a data plane encapsulation is great for DC/Enterprise and some ISP applications, but MPLS is still the gold standard for most every ISP in the world to deliver overlays and implement traffic engineering.
Also, now that we know MikroTik is working on EVPN, I hope they develop it with MPLS in mind. The SR-MPLS data plane is what EVPN was designed for and VxLAN was added later.
MPLS is definitely not stable as of 7.17 as I posted earlier. Again I suspect its LDP specifically that is the problem and not MPLS itself. So I could use BGP which requires a major overhaul, it’s firmly in the too-hard basket. If they do pull their finger out and finally release MPLS SR then it’s something worth the effort as that solves many of the major design constraints I have
TBH it seems like ROS v7 is just a waste of time, it’s still missing a lot of important ‘networking’ features, and many others that are half assed. It has been years and its fallen miserably short of the promised land. I’d rather they just stop where they are and start working on v8, leave a lot of the functionality to pre-existing code bases and build upon it. Not try and re-invent the wheel with an old outdated kernel that v7 is based on
What makes you think starting a v8 branch would change anything? IMO (and just speculating here) MT would really benefit from reorganizing and establishing an R&D department dedicated specifically to enterprise networking. Of course, priorities and development direction naturally depend on their target audience.
1 Like
Because instead of reinventing the wheel themselves, they can just borrow a lot more pre-existing code and leverage it. Much like they (finally) did with wifi, dumped their inhouse drivers which were woefully underperforming and used standardized drivers. We as the consumer finally got wifi that wasn’t just embarrassingly bad, i’d like to see their routing capabilities up to scratch as well. What a miracle it would be if we finally had things like Segment Routing, Fast Reroute, working IS-IS, Feature complete BGP that wasn’t borked, etc
Are your IGP/LDP timers matched? The behavior you described could occur even in ROSv6 and setting the LDP/IGP timers to match - especially the hello timer was always the fix.
If you haven’t done that, it’s likely why you’re still having issues.
And where would they “just borrow a lot more pre-existing code” from ?
Exactly, BIRD and FRR are great but neither is anywhere close to the feature set for routing in MikroTik. It doesn’t mean I think MikroTik is perfect or doesn’t have room for improvement but there is nothing out there in the OSS world of code that has SR-MPLS + EVPN + L2 ELINE/ELAN/VLAN integration with an EVPN MAC VRF.
If you believe there is @millenium7, kindly point me to this Unicorn lol.
Just hello timers between LDP and OSPF, or is there more to this?
Yup, matching hello timers between LDP and OSPF generally keeps the IPv4/IPv6 routing tables and MPLS forwarding tables in synch since they’ll both clear at the same time if there is a neighbor down or a flap. In Cisco/Juniper/etc there is a protocol for this call LDP/IGP synch but setting the timers to match has a similar effect.
It’s also wise to filter ldp to just the needed routes. If you’re only running VPLS, then just allowing the loopbacks in/out is sufficient.
Similar thread here about the same issue in ROSv6
http://forum.mikrotik.com/t/mpls-ldp-still-not-stable/148729/1
Thanks for that info Kevin