MikroTik newsletter May 2020 (#95)

MikroTik newsletter May 2020 (#95)
Read our latest newsletter and learn more about:

• Covid-19 update
• hAP ac³ LTE6 kit
• CCR2004-1G-12S+2XS
• CRS326-24G-2S+IN
• UNII-2 support for the United States and Canada
• ServeTheHome: “..best value 48x PoE+ on the market?”
• MikroTik switch in Linus Tech Tips

https://mikrotikdownload.s3.eu-west-1.amazonaws.com/news/news_95.pdf

The CCR2004-1G-12S+2XS looks promising. I would like to see some speed test results of GRE and EoIP over IPSec. With the current generation of CCRs (TILE) the results of using plain ipsec and tunnel over ipsec differ by a mile.

Will CCR2X series come out straight with ROSv7 or will it be part of the v6 family first?

Do you have more information about that Annapurna AL32400?

Unfortunatley every time MikroTik features in a Linus Tech Tips video he never gives the product the showcase it deserves, makes me wonder if he really understands it! After watching their 10 Gbit home network video a while back and they were having trouble figuring out how to configure it/couldn’t find winbox so the video just cut to when it was done lol.

It has four cores. See here for details of CCR2004:
https://mikrotik.com/product/ccr2004_1g_12s_2xs

Only 4 cores for such a huge amount of SFP+/SFP28 interfaces… Is there any other way more powerful version on the roadmap?

Well, looks like the CCR1016-12S-1S+ is pretty much dead now. But the test results have me scratching my head. Either a box is PPS (CPU)-bound, or it is IO-bound. Looking at the block diagram, you can push a maximum of 50 Gbps through it (port extender uplink to the SOC is 2x25G).

Yet the box maxes out at ~2.8 Mpps fastpath at 1518 byte packets, giving ~35 Gbps. As that isn't really close to 50G, it looks it's CPU-bound. But going to 512 byte packets, the PPS more than doubles to 6.2 Mpps, showing that it wasn't. Going to 64 byte packets the PPS again goes up by a factor of 1.5 to 9.2 Mpps. So if it can do 9+ Mpps, why can't it get closer to 50 Gbps at larger packet sizes? :confused:

And at 35 Gbps going flat out the box is oversubscribed by a factor of 5. And that's in the absolute best case. If you want it to do anything more than just slinging max size packets, it's going to be closer to a factor 30. A CRS has the excuse that it's a switch (and can do L2 at speed) for L3 oversubscriptions like that, but this is supposed to be a router... I can see it being a VPN concentrator or BGP RR, but you don't need the 25G (or even most of the 10G) ports for that.

I'm not really getting this, to be honest.

Good to see a desktop version of the CRS3XX line. I need the CRS112-8P-4S-IN upgraded to the CRS3xx hardware and have 16 ports, rackmount or desktop (short depth PoE switch).

Linus is a nice dude that honestly likes technology.
But when it comes to networking he simply doesn’t know much about it. (Check an old Infiniband video that he did that shows clearly the lack of knowledge on networking)
So I don’t expect him anytime soon to give RouterBoards and RouterOS the attention they deserve.
Even STH don’t seem to show what the platform can actually do.

Anthony is probably the only guy in LMG that can understand complex network stuff (but doesn’t necessarily knows them in advance).

Besides, their (gaming) audience is not that advanced to even understand what RouterOS can actually do.
They obviously prefer RGB :laughing:

Why are you making these black cases? Well, couldn’t you have made a normal case for hAP AC3? Like the hEX S by color, or classic white? Again, this “cheap” case as in the “lite” version.

Could it be a mix? The only part of the packet that uses CPU power is the header, the payload is just using memory bandwidth. Maybe with the 1518 byte packets its memory is bandwidth starved, and the CPU isn’t maxed out. When it get smaller packets we use more CPU - as the payload gets smaller - than memory bandwidth. This way we don’t have a smooth curve, as we are used to see.

Going down to 64 byte packets, it finally gets CPU starved - and we see the pps and bps falling.

Yeah, but that’s not what happens. If we assume that 35 Gbps is an IO limit (not due to the interconnect but something else, like memory bandwidth for instance as you say), the 64-byte result proves that the CPU can do 9.2 Mpps. Then why isn’t it doing 8.5 Mpps to get to the same 35G at 512 bytes? The CPU can do it, as it proves when shuffling 64 byte packets, and the IO subsystem can, as it proves with the 1518 byte packets. Yet although PPS goes up, total BPS goes down for both 512 & 64 bytes. That makes no sense; it isn’t hitting either IO or CPU limits yet at 512 bytes.

When you look at the results for other boxes, like the CCR1016, they behave more or less like you would expect; either 1518 bytes IO bound (by combined bandwidth of the physical ports) and 512 & 64 bytes CPU bound with roughly the same PPS and lower total BPS, or 1518 & 512 bytes IO bound with roughly the same BPS and 64 bytes running out of CPU with higher PPS buth lower total BPS.

If I remember correctly, these tests measure the speed of the payload traffic, not the speed at ethernet layer. That would explain the difference: due to the header overhead it hits the (theoretical) 35Gbps ceiling.

Hello. Interesting point of view about the performance.. what about a comparison between the 1036 and one of these in terms if pure speed? We use 1036 at core with 4.5 gbit per second fastrsck with cpu 15%… this new router seems interesting so i can avoid a switch for trunk in 10g ports, but the max throughtput will be lower…

Nice products for this newsletter. I would love to see Mikrotik on the CRS3xx line to have PoE+ included, and mGig Ports instead of normal 1 Gbps ones. That will make this switch (and the rack mount version a very compelling device.

Still I like the new CRS326 desktop version but the next level for me will be to have these features out of the box.

Do you expect an answer from MT on this? They will not respond. :slight_smile:
My guess, no, v7 is in early beta stage.

That’s not what the test results indicate; 1518 bytes is a full 1500-byte MTU Ethernet frame, and the BPS & PPS rates match those 1518 bytes. So do the other two, where 64 bytes is of course the minimum Ethernet frame size. So in the published numbers the entire frame is counted, not just the payload.

True. Time to find a new hypothesis. But it is clearly hitting some limit, and I don’t think it is software related.

What irony in NEWSLETTER you show a photo of Nexstream employees from mikrotik sxt lite5 with software from … Cambium.
During the epidemic, it is very clear how much MIKROTIK suffers from the lack of a good p2mp protocol. Any AP where many clients have launched a home VPN // Video teamwork almost ceases to work 802.11AC + RTS / CTS completely fails. NV2 supports only 20Mhz channels with full scaling and only 20-25 clients without any degradation of spectral performance.