Is there any plans on label switching MPLS (P not necessarily PE roles) for CRS3xxx series?

Also; Are there any CCR's that might be able to do something in this area (hw offloaded) in the future?

There are plans on implementing MPLS hardware offloading at least for Marvell 98DX8xxx switch chip series (CRS317, CRS309, etc.) and CCR2116. However, please don't expect that soon - we have to finish IPv6 offloading first.

It is unfortunate that Mikrotik does not prioritize MPLS hardware offload!

It is unfortunate that Mikrotik does not prioritize MPLS hardware offload!

They are prioritizing it. It's just behind other things like fixing the usability bugs in RouterOS v7.1 and delivering MPLS as well as IPv6 FastPath modules, and for good reason!

There are plans on implementing MPLS hardware offloading at least for Marvell 98DX8xxx switch chip series (CRS317, CRS309, etc.) and CCR2116. However, please don't expect that soon - we have to finish IPv6 offloading first.

Would you know if, when eventually available, it would be able to offload as both P and PE? Or would it be limited like the ROSv6 implementation where it could only offload when label switching as P?
If the former, would you know if it would be able to also L3HW VPLS?

any hope for this featureset to materialize?

It would be great to have that functionality.

It's a bit strange to begin with IPv4&6 HW offload, and not MPLS. All major providers use MPLS for carrying internal traffic between core nodes.

IPv4/6 offloading only work with plain forwarding, and people except to be able to use complicated firewall rules, nat, tracking, pppoe, tunnels and other stuff that will break it. It will basically only work for "inter VLAN routing" with some simple ACLs.

It's a bit strange to begin with IPv4&6 HW offload, and not MPLS. All major providers use MPLS for carrying internal traffic between core nodes.

Around 99.99 (add a few nines behind) percent of users use plain routing (either static routes or OSPF/BGP) and only small number of users use MPLS. Even fewer of those users are currently Mikrotik customers. Only telecoms and some really large corporations use MPLS inside own networks, inter-VLAN routing is pretty common though.

So while the request for MPLS HW offloading is certainly a legitimate one, I guess it's pretty low on ToDo list of MT devels.

The most cases of inter-VLAN routing have some kind of firewalling in mind, and that most likley will break the HW acceleration. The hardware can never fit a full real-life Internet BGP-table either.

MPLS is used by many smaller WISP/ISP for VPLS services customers and VPN VRFs.

As explained in L3HW thread, fasttrack is being HW offloaded. Which means that most of traffic can be offloaded. The only big problem for such offliad would be handling a DDOS attack which would hit main CPU pretty hard.

Please explain how MPLS switching compares to routing (which by your words includes firewalling)? I don't think that ISPs firewall traffic between their customers even if they don't use MPLS and only route (in which case a L3HW device would do pretty well). Also most of ISPs don't configure CPEs as MPLS edge routers, my impression is that edge routers are often one layer closer to ISP's core network.

this escalated quickly...

Here is the reasoning: ROS v6 already supported MPLS in Hardware on the CRS317 platform.
This feature was removed (for now) in v7 https://help.mikrotik.com/docs/display/ ... offloading

For those using this feature - upgrading to v7 is off the table, although probably L3HW upgrades would be nice.
The thing is if you got MPLS using v6 on these boxes, then you already have some sort of hardware-forwarding, but of course for labels only.

so - imho - those v6 users having mpls in hardware would simply like to see the feature parity in v7 for this, especially for migration-purposes.

Doing routing and other stuff is not exactly new as there were lots of so called Layer3 switches before the 98DX Marvell chipsets, yet MPLS in hardware is not so easy to come by - therefore I hope for the best and a v7 implementation in the not so far future

keep in mind RouterOS 6 MPLS hardware support was only for CRS 317/309 switch, and Only for P router role, was a very limited scope and not a complete hardware offloaded MPLS solution, with PE role router still on software

It's a bit strange to begin with IPv4&6 HW offload, and not MPLS.

It's not strange at all. LDP requires IPv4 or IPv6 + an IGP to build the forwarding table of label bindings so ensuring that IP forwarding is working correctly with offload is foundational work to enable MPLS and offload.

It's also the one of the hardest protocols to get right when developing for an ASIC so tackling easier protocols first is understandable.

I can't wait for MPLS hw offload - it's going to solve a ton of problems for ISPs and DCs that use MikroTik

So while the request for MPLS HW offloading is certainly a legitimate one, I guess it's pretty low on ToDo list of MT devels.

primary use-case is VPLS VPNs for customers.
EoIP works great and all but adds tons of overhead and has performance issues at high speeds. would be awesome if we could replace all our EoIP with VPLS.

It's also the one of the hardest protocols to get right when developing for an ASIC so tackling easier protocols first is understandable.

I'n my view it should be the simpliest. The MPLS FIB is basically Label in & out and swap or pop.

HW NAT and/or HW IPv6 sounds like a logical nightmare.

It's also the one of the hardest protocols to get right when developing for an ASIC so tackling easier protocols first is understandable.

I'n my view it should be the simpliest. The MPLS FIB is basically Label in & out and swap or pop.

yes but it runs on top of conventional routing, so not only do you need MPLS to work right, but everything it runs on top of as well.

No. The CPU does the FIB calculation, then the forwarding is done in hardware.

There are plans on implementing MPLS hardware offloading at least for Marvell 98DX8xxx switch chip series (CRS317, CRS309, etc.) and CCR2116. However, please don't expect that soon - we have to finish IPv6 offloading first.

If are there some news about MPLS offload?

I have some pop's using the CRS305-1G-4S+ who use the Marvell 98DX3236. In the next couple of months, I was planning config MPLS in these equipments.

I'd like to know how would it manage the config?

Looks like MPLS Fast-Path is scheduled for ROS 7.10

https://help.mikrotik.com/docs/display/ ... l+Overview

I hope this might be a sign that MPLS EXP bits might get fixed soon. We can't move many routers to v7 until MPLS QoS is working correctly again.

any update on this feature? we have multiple CRS326's out at sites and really want to start expanding our VPLS/MPLS network on to the switch itself

We are also waiting for MPLS HW offloading. Is there a schedule? at least a year?

MPLS offloading is one exciting thing we all waiting for.. I still have my CCR2216s with CPUs running high because most of my traffic is MPLS.
Is there a timeline for this feature?

Hello,
has anyone heard anything on the topic?
In the last beta versions nothing seems to indicate that there is any movement here?

thanks,
glueck

Hello,
even in the last beta versions there is no sign that things will continue here.

@Mtik: Is the topic no longer being worked on?

regards,
glueck

Is there anything new on this topic? Maybe in 7.16?

I have not read anything associated with this topic. I think the "HW offload team" is working on QoS implementation.

I know it's been mentioned as a suggested priority by several people in the MikroTik community that are close to the dev team. I've advocated for it since day one of the Marvell chips being introduced.

My guess is that if it's not added in 7.16 beta, there is prob some blocker they have to work on to get it running/stable/etc.

The main point of MPLS Hardware Offload is the common protocol to Cisco, Huawei... vendors to provide BGP Free Core, VPLS, L2VPN and L3VPN services in wirespeed.
A ISP that are buying a switch with 16x 100Gbps port is not a small ISP and probably is delivering all the services that I listed, so solution like Huawei and Cisco are better options, but when Mikrotik implement a full MPLS hardware offload this vendors will be less used because of the price and commodity of the winbox interface.

Hello everyone, the announcement of the CRS520-4XS-16XQ-RM has given me some hope that work on MPLS HW offloading will continue. The marketing documents clearly and often talk about additional functions that are to be carried out using hardware. Let's see whether Mtik also has a clear focus on MPLS here? A rough timetable would be nice.

I thought the same when I saw the announcement video. But who knows, it could also be VxLAN.

I've advocated for it since day one of the Marvell chips being introduced.

My guess is that if it's not added in 7.16 beta, there is prob some blocker they have to work on to get it running/stable/etc.

Here's the thing: it EXISTED in RouterOS 6, and works perfectly freaking *fine* on RouterOS 6.

The situation we are in, where RouterOS 7 has reached .18 and we STILL have not had this feature re-added back for those that depend on it, is ABSOLUTELY absurd. And it is a major blocker that PREVENTS those of us who use it on RouterOS 6 from upgrading our networks to 7.

IT HAS BEEN FOUR YEARS. I'm not pulling punches anymore on this subject.

Here's the thing: it EXISTED in RouterOS 6, and works perfectly freaking *fine* on RouterOS 6.

you forgot to mention only worked on some specific devices (CRS317-1G-16S+ and CRS309-1G-8S+) and only for transit, popping MPLS labels from packets still had to be done by CPU

however i hope this can be solved soon

I've advocated for it since day one of the Marvell chips being introduced.

My guess is that if it's not added in 7.16 beta, there is prob some blocker they have to work on to get it running/stable/etc.

Here's the thing: it EXISTED in RouterOS 6, and works perfectly freaking *fine* on RouterOS 6.

Yes, but it was a different linux kernel and they pulled it back out of ROSv6. So there had to be some issue with it.

You're not wrong though. MPLS in hardware is long overdue and it needs to be a priority for the MikroTik devs in Q2.

you forgot to mention only worked on some specific devices (CRS317-1G-16S+ and CRS309-1G-8S+)

`
I didn't "forget to mention it". The context was, as StubArea51 put it, "day one of the Marvell chips being introduced". The Marvell switch chips are only used in certain products, of course. Only certain models of Marvell switch chip support MPLS label switching, so only those models were supported. Finally, CRS309 and CRS317 were the only two models of anything with the proper Marvell chip in them that MikroTik had released prior to RouterOS 7 finally coming out of beta.

So it was all obvious from the context. No hardware released since RouterOS 7 came out has ever supported it, obviously, because RouterOS 7 wholly lacks support for the feature, and none of those devices (e.g. CCR2116/2216, CRS5xx) can be downgraded to run on RouterOS 6 since ROS 6 obviously lacks all hardware/driver support to run on those models.
`

and only for transit, popping MPLS labels from packets still had to be done by CPU

`
See below.
`

Yes, but it was a different linux kernel and they pulled it back out of ROSv6. So there had to be some issue with it.

`
Look, here's the thing: MikroTik releases the CRS309 and CRS317, and promises "HW MPLS forwarding coming in future software update" (Newsletter 77). This support is released in RouterOS 6.41 (end of 2017). It is clear that this is P-router-only (only label switching, no push/pop) to anyone paying attention. To this day, even the CRS317 brochure advertises "HW MPLS forwarding".

Based on all of this, several years ago, we got a 317 in order to play with this feature in the lab. After getting it working successfully and liking the results, WE BOUGHT A WHOLE BUNCH OF THEM AND DEPLOYED THEM IN PRODUCTION as 10gig P-routers. And guess what: in that role, they work great. Would it have been nice if they also supported label push/pop and VPLS encap/decap in hardware? Sure. But we were happy just having these in the transport path, and using e.g. CCR1072 as PE-router for those functions when 10gig was needed at the edge, or something lesser if particular PE didn't need to be 10gig.

So in our experience, there was no "issue" with the feature, in terms of it being buggy or not working as-advertised. Maybe there were issues with the old implementation under the covers that was hamstringing further development, but frankly...that's not our problem. And it is downright irresponsible to completely REMOVE a WORKING feature FOR FOUR YEARS that had been previously delivered and marketed, and that at least some of your customers then became dependent on. I can understand the possible need to refactor or completely rewrite the feature from scratch, especially if that is required in order to add support for additional features. But I don't see how that prevents you from CONTINUING to ship the originally WORKING feature while you undertake that effort. We don't need HW MPLS support to magically drop from on-high with 100% of all features working when it does. What we need RIGHT NOW is ONLY the label-switching part that WE HAD BEFORE. That will tide us over just fine until the new implementation is ready along with all of the associated "cool" new features it brings.

By MikroTik removing the hardware label switching support entirely from CRS309 and CRS317 while they "regroup" on the effort, we have been prevented from upgrading our network to RouterOS 7, since upgrading our CRS3xx P-routers is out of the question (poor little ARM CPU will get slammed), and we aren't willing to move to a hybrid ROS 6/7 network since we don't want to deal with the potential headaches resulting from OSPF and/or LDP interop bugs between ROS 6 & 7. And ripping-and-replacing these CRS3xx devices acting in the role as P-routers on our network would be such a massive and expensive undertaking (both capital and labor-wise) that it is hard to even fathom going down that path...if it ever came to that, there would be so much bad blood between us that we would likely just say goodbye to MikroTik entirely. So MikroTik has completely ****ed us over by getting us dependent on their product, releasing ROS 7 without a headlining feature that previously EXISTED and which we NEED because we are already USING it, then putting ROS 6 into effectively maintenance mode and only fixing security vulnerabilities in it. And since all of their new hardware is all ROS 7 only, it means we can't freaking USE any of it until this ABSURD situation is resolved. We. Are. Stuck.

The correct, right, and responsible thing for MikroTik to have done here would have been to 100% prioritize making sure that ROS 7 could match ROS 6 feature-for-feature BEFORE they started chasing after the fun and sexy new features that the new Linux kernel would enable them to provide. But they apparently lacked the discipline to do so, and they decided to have dessert before dinner instead, screwing over many of their users in the process.

i think v6 MPLS working feature got in the way of L3 hw offload maybe thats the reason to drop the MPLS feature as a temporary measure..

however

here we are more than 3 years after the introduction of v7 and that is not fixed, very disturbing to say the least

i think v6 MPLS working feature got in the way of L3 hw offload maybe thats the reason to drop the MPLS feature as a temporary measure..

`
Maybe you're right; since we have no visibility into the situation from the outside, we can only speculate. But this just goes back to my concluding point:
`

The correct, right, and responsible thing for MikroTik to have done here would have been to 100% prioritize making sure that ROS 7 could match ROS 6 feature-for-feature BEFORE they started chasing after the fun and sexy new features

`
Back during ROS 6, nobody was dependent on the non-existent L3 HW feature. But there WERE people dependent on HW MPLS label switching. So it was ABSOLUTELY irresponsible and undisciplined of them to chase after L3 HW before it was possible for them to deliver it working in harmony with MPLS HW. No "if"s, "and"s, or "but"s about it.

i think there is no priority for Mikrotik with this matter if it was important they at least will tried to get the old MPLS feature working even being mutually exclusive with l3 hw offload on v7, at least until they can make it work simultaneously, but nothing close to that happened...

i think there is no priority for Mikrotik with this matter if it was important they at least will tried to get the old MPLS feature working even being mutually exclusive with l3 hw offload on v7, at least until they can make it work simultaneously, but nothing close to that happened...

`
I agree that it seems like they do not prioritize it and do not seem to think it is important. My argument of course is that they SHOULD have prioritized it, it SHOULD be important to them to not screw over their customers, and it is DAMNING that they did not [prioritize] and it apparently is not [important].

And yes, having L3 HW and MPLS HW be mutually exclusive would have been a good intermediate compromise. They should have done this. It's not like they haven't done anything like that before. Heck, MPLS HW offload on RouterOS 6 with CRS317 cannot be used in conjunction with hardware-switched VLANs on CRS317, so there were already major limitations and exclusions!