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.
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.
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
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.
`
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.
`
See below.
`
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
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 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!