I ran simple tests with VRF and hardware offload using CCR2116 and CRS326-24S+2Q.
Initially, I only used static routes, without any routing protocol or route-leaking between VRFs. I also didn't test anything with stateful traffic.
I couldn't handle much traffic. And I didn't even check if SNMP works well, much less IPFIX or other similar features.
But the simple tests got me excited!
On the CCR2116, I think I saw some small spikes in one of the CPUs randomly. On the CRS326 (single core 650Mhz), the CPU spikes were more evident, similar to what was seen with Hardware Offload on the Main-Routing-Table, but a little more intense.
If I can juggle my schedule, I'll be able to run tests with routing protocols this week.
This should be tested with CRS 326 switch to fully validate if it's working realistically I expect the throughput should almost the same without VRF with reasonable CPU usage, if this works reasonably well we can change our SOP how we deploy service to customers very exciting
In my intended scenario, I will need some of that 650Mhz MIPSBE for OSPF with less than 200 Routes. And also for BGP with L3VPN, with less than 1000 BGP routes in total (vpn4+vpn6)
In my use case there's no control plane just pure L3 switch with hardware offload on top of Router on stick with ccr1036
My 2nd scenario is just like yours so that we can maximized CCR2216 and allocate portion of its resource to some customer, I hope this works feeling excited to lab this up
Correct me if I'm wrong, but isn't MPLS data plane offloading still unsupported in L3HW? I'm curious since it sounds like you are about to test L3VPN with this new release.
when i add macsec to a port, both parent port and macsec interface show red warning 'same mac-address as (the other interface)' is it a bug/feature? should i worry?
You are correct! MPLS L3HW still it's not supported!
You are almost correct about me trying to tests L3VPN on it.
I still need some dots being connected...
But I hope to be able to do some Jerry Rig with EVPN + VXLAN to in some way com create some kind of fake/remote VRF-Lite.
P.S.: EVPN route type 5 would be good at this time.
Regarding the difference in available disk space, there are old crash logs stored on the device with serial number D7XXXXXXXXXX, which account for the discrepancy.
Reinstalling RouterOS on the device would perform a disk format, resulting in similar free space on both devices and allowing the upgrade to proceed under the same conditions.
As the software evolves and consumes more disk space, it continues to fit within the internal storage capacity of the router. We continuously improve and optimize RouterOS and its features to support our devices.
The hAP ac² has sufficient free space when using the recommended wireless package. However, due to the device’s 16 MB storage limitation, using the wifi-qcom-ac package may not be the best choice.
If your setup requires the wifi-qcom-ac package and additional features, you may need to consider upgrading to a device with larger storage capacity.
Thank you for sharing.
Actually, it is a very strange answer, because it is not only a hAP ac2 problem; the problem I have is with cAP ac – the device specially made as an access point – and wifi-qcom-ac provides a better wifi experience and supports new Capsman.
The 16MB flash AC devices were always some kind of bastards when it comes to (new) wifi drivers. When wifiwave2 was first introduced with ROS 7.0, it didn't support these devices ... and hAP ac2 was cited as not supported due too little RAM (initial wifiwave2 required at least 256MB RAM) even though some initial production batches actually had 256MB RAM installed. MT did come forward with introduction of wifi-qcom-ac package which eventually added support for (new) wifi drivers on those "bastard" devices. But it seems that the "steam of support" somehow disapeared
I've heard this argument before. Since then, I've been speculating that the arm routeros package grows so much that even the wireless package no longer fits. Then they'll have to do something about it (5-year update guarantee from the date of purchase.)
Yes there of course is the never ending discussion if it would not be better to split RouterOS and even the driver packages into multiple smaller ones (as it was in v6), and also if it isn't time by now to have a "RouterOS lite" that lacks all the "big network features" and focuses on typical home network NAT router and access point tasks.
However, nothing has ever come of that. I can understand that MikroTik does not like the idea of having two versions and two different cases in support (I don't think it needs 2 source trees, it could just be compilation options). But the users of 16MB devices are left with the problems. They see their device filled to the brim, and never use all those advanced features, they only confuse them.
This is great news. I have not done much testing yet. But one thing I noticed is the version field does not seem to do any validation on validity. For example, version=1.2.3 or version=a.b.c are accepted. Ideally, the version be check on set/add, or at least some static validation of the arg type‡ so it "looks like" a RouterOS version (prefix with 6/7, etc). e.g. some super type, CLI Reference | RouterOS Manual
‡ Which highlight the need for per-version CLI Reference since I cannot actually lookup the current arg type from manual.miktoik.com, since it's new version, but /console/inspect suggests it accepts any string.
Unless someone from Mikrotik comes to contradict me.
I don't believe MPLS will go into the Hardware Offload feature set.
I don't remember much about MPLS support on Prestera chips. I'm sure Label Swap (P.Router) is supported by Prestera, and if I'm not mistaken, encapsulation should also be supported by SwitchChip features. But it must compete directly for some other important feature resources for MikroTik's market.
So I recommend starting to think about other methods to achieve Underlay/Overlay with VRF and hardware offload.
Putting together what we have so far with RouterOS, I bet the most likely path is EVPN Type5 Route over VXLAN.
P.S.: It would be quite appropriate for this type of information to come in a Roadmap section in the official documentation.
In our case, we currently use MikroTik devices as PEs in sites where the traffic volume allows it (running it in software). For locations where MikroTik boxes hit their CPU limits due to the lack of L3HW for MPLS, we deploy hardware from other vendors that natively supports MPLS push/pop/swap at the ASIC level.
That said, we still hope to see hardware MPLS support in the future, as MikroTik RFouterOS is a highly versatile platform.
