Yes, it’s a pity. Lots of low(ish)-powered cores like the TILE is a good architecture for packet forwarding. Looks like MT is again going with the ‘throw lots of cores at the problem’-way of things they did with the CCR1036 & -72, but now in quite another weight class (see the Ampere ROS that’s coming). The Ampere Altra starts at 32 cores and goes up to 80, the Altra Max up to 128. And those are up to 3GHz 64bit ARM cores, not the 1.2Ghz 32bit cores the old TILEs had. Even a CCR based on the cheapest Altra (32 cores at 1.7GHz) would have a CCR1072 or CCR2216 for breakfast, CPU-wise.
Not going to be cheap, though; that Altra CPU alone is $800,= in lots of 1000.
I didn’t mean to imply MT had anything to do with that. Tilera got eaten by EZChip, EZChip by Mellanox, and Mellanox by Nvidia, which owns the IP now. Nvidia still makes BlueField DPUs (which they got from Mellanox and is kinda ‘Son-of-TILE’), but they killed off the Tile-GX CPUs the CCR1 series is based on.
Please don’t whine to me about “user” router, I’ve dealt with networks bigger than your “500.000” crappy NATted network.
If you need REAL CGNAT, then buy a REAL x86_64 box and use DPDK/VPP for REAL CPU fast-path, or XDP to offload the CGNAT to the NIC.
Or ever thought about offloading 80% of the traffic to IPv6? Didn’t think so.
Queing? Use LibreQoS.
QinQ, while it is a traditional telco approach to customer layer 2 isolation. There are more modern ways to do it, combine PON isolation/wireless isolation + “private VLAN” on the L2 transport devices (possibly including the PE router) + “local-proxy-arp” on the BNG unit + DHCP Snooping on the respective L2 transport devices (or again possibly, PE, depending on your exact config), and you’ll never need QinQ ever again.
1)So if you need or want to use MPLS you have to buy Juniper? And why not Cisco or Huawei or other brands? This is a fanboy position…
2)Is this the game of who’s got the longest?
3)Another time you propose a software as solution to all problems…
4)I called every telco I have to deal with and showed them your solution. They appreciated it but told me they won’t change their networks so I still need the QinQ
Anyway, i also have a 2216 used for mpls as PE, one bridge with vlan filtering, l3hw enabled. Cpu 100% and PL at about 10-11 Gbps even with last beta
I opened a ticket and waiting for support.
Have fun with Cisco’s licensing fees and model. Huawei is not allowed to be used in certain countries due to regulations and sanctions against the Chinese, I’m surprised you support the communist agendas, sounds like we should be wary of your advice. Nokia is a solid choice too, but very expensive, than just a plain MX204 refurbished.
Probably, yes. Why do you care? Would you like to measure up, as well?
I don’t think you understand what LibreQoS is and how modern queuing is better offloaded to the NIC on x86_64 with fq-codel and AQM/SQM.
Too bad, so sad. I run my own networks with my own transport or plain dark fibre with DWDM, and have no problem deploying modern-day solutions, I’m not a slave to some Telco running on some legacy MPLS core with 6PE.
I have talked to our bigger experts about this case, so to the OP:
In your example you are comparing different architectures, you are saying your TILE router had only around 1% CPU useage, but in your ARM router it’s around 25%, while as far as I can see, performance is still very good. This is because in the case of TILE CPU, a lot of operations are done differently. When some tasks have to be divided to many CPU cores, packet loss and out of order packets can occur. The ARM CPU is smarter in this regard, there is a lot more processing done, so that this does not happen. In any case, you are still not utilizing even half of the available CPU power, so you should be good even with much bigger networks.
We are not saying that there is nothing to improve. Software can always be improved. That is a never-ending story for any software, not just RouterOS. But comparing different architectures and drivers simply is not fair. They each have their pros and cons.
v7.13beta2 has several improvements for this device, so when it’s more stable, try and test that one. But in the end, it seems the slightly higher CPU load is very good news, as the CPU is simply better and does stuff TILE was unable to.
Why not just offload heavy-duty data-plane stuff (MPLS, VPLS etc) to the respective switch-chips (where supported) on MikroTik hardware, instead of relying on CPU for every single thing?
I feel MikroTik is pushing too hard on CPU reliance for everything, and that’s why people have these various performance issues/situations.
Or at least make use of DPDK/VPP and/or XDP to push CPU performance to the edge.
I think this should be listed officially on MikroTik official documentation to avoid duplicate forum threads. Even I didn’t think about how TILE CPU architecture could be responsible for TCP dup acks, retransmissions etc. Which makes sense to be documented officially.
1)I don’t think my support of the communist agenda is any of your business or anything relevant to the thread… i can say the same, you are supporting a stupid ban imposed from a country that spy on enemy and even allies for years. Ask Snowden for confirmation…
2)no thanks, I stopped doing that since kindergarten
3)once again you make inferences about the level of knowledge of others to justify having once again given a software as the panacea for all ills. Just 42 is the answer to everything
4)You’re the man! Here is simply not possible to do this so you have to use one of the two nation wide fiber network available that are not smart like you and still use QinQ.
@Mikrotik please remove mpls support from ROS. When a user click on the button on winbox a popup will show “Please buy Juniper! Contact Darknate for further informations”
The case I presented with the picture of CPUs usage is a Full Internet BGP router. With that we have started experimenting with L3HW, with quite good results (we have some doubts about some detail and how we can force some prefixes go to HW, but we’ll eventually do a separate post).
The other (harder) case is an MPLS PE with a couple tens of VPLS, a few with many Gbps of traffic. Here with CCR2216 we have seen a great usage of CPU, almost all in IRQs, so simply to transfer bits from switch to CPUs. We found that in hours of maximum usage, even if average CPU usage was under 40%, one or more CPUs were constantly at 100%. And in these cases we found sensible packets loss (even more that 10%!).
Using a CCR1072, the average CPU was less that 1% and maxium always much lower the 100%. And there was NO packet loss!
So, in this particular scenarios (MPLS/VPLS), but maybe some others (CGNAT, queues, etc.) where HW cannot be used, the old CCR10xx platform is performing much better than new CCR2216. Not because of better CPU but because better IO efficiency.
There is a chance this will improve in the future. The switch ASICs in CCR22xx support many HW features not implemented/exposed in ROS. Not only MPLS, also VXLAN and more. (VXLAN currently also lacks HW support on CCR22xx although the ASICs could do it).
As you described, with the recent IPv6 l3hw fixes the CCR22xx is currently starting to become usable as a large/full table edge router with HW acceleration. And there it provides much more bang for the buck compared to similar big brand boxes.
For more advanced stuff, we have to wait until MT makes the switch ASCIS features available and configurable in ROS.
With CCR22xx, MT has entered a price/customer range where the usual sloppy Mikrotik approach to SW stability, maintenance and roadmaps (and last but not least the poor handling of CVEs) is not acceptable. So again there is hope for improvement.