Feature Request: Include NAT speeds in Mikrotik Test Results Documentation

RouterOS General
1

Feature Request: Include NAT speeds in Mikrotik Test Results Documentation

I really would like to see Mikrotik include NAT speeds in their published product Test results.

We’ve seen it many times in these forums , where somebody posts a topic about slow Internet performance. Then often follow-up posts from others state to use/get a faster mikrotik router.

Example:
hEX PoE
Nat-Specs.jpeg
Nowhere in the above Mikrotik test results documentation do you see any information as to how fast the product will Nat.
Yes - there is some routing information in the above image , but which line for Routing should be used to estimate the speed a NATted client behind the Mikrotik ( LAN ) should be able to get when going to the Internet ( example speedtest.net ).

FYI - Moments ago , I configured a hEX PoE ( 1-Gig SFP WAN uplink and 1-Gig ethernet link LAN to a PC-computer ).
No simple queues , no filter rules - just NAT from LAN to WAN.
The best speed a PC on the LAN could get was around 250-Meg using www.speedtest.net
My other non Mikrotik router was getting almost 999-Meg with similar NAT configurations and IPs.


Yea - I know this is not a high-speed router - but without Mikrotik NAT speeds in their published test results , it’s a best guess for NAT speeds.

North Idaho Tom Jones

Question - what small Mikrotik ROS product ( similar in size and price to the the hEX PoE ) , that has one sfp port and at least one Gig-ethernet port and can nat at near 1-Gig speeds ( customer going to www.speedtest.net )? ( Hex S ??? )

2

Agree. Or, in general, a few more tests to better capture the different performance aspects of the various models.

Although, “forum rule of thumb” is using the 512-sized 25 ip filter rule as a general guide to internet performance. On that score, your 250Mb/s is not too far off that 319Mb/s. Speedtest is TCP, but SYN/ACKs are small packets, so average packet size is lower than UDP. i.e. in test results, the 74-78k packets/sec is pretty fixed. So, for example, a UDP-based iperf/etc likely averages above the “512-size packets”, with the lower overhead, that increase average packet size. So more data using the same ~75kp/s “budget”.

Anyway, agree on NAT (+more) test results specs. Only minor point that your example does track with the “512-sized 25 ip filter rule” :wink:.

3

Based on your previous posts there must be some gotcha to your question, but I’ll bite.

To make sense of the test results, we first look at the size of the packets. Simple IMIX assumes an average IP packet size of 340 bytes. Were we to assume that a TCP connection has one ACK for every full-size frame (which is not necessarily true for every implementation) then we would have roughly 780 bytes per packet on average. Of the columns, 512 is the closest. (We see that Mikrotik includes the ethernet header and the FCS in its sizes, so 512 is actually 496 bytes IP.)

What row should we look at? We are performing NAT so connection tracking must occur. Once connection tracking occurs, it is meaningless whether we have 0, 1, 25 or 100 filter rules. (And yes, I’ve measured. There is of course a measurable difference, but nothing that would actually matter in real life. By having these many filter rules, I of course mean “normal” ones, that match ingress/egress interfaces, protocol, ports, addresses etc., not L7 filters, SNI, etc.)

So we get the number 319.5 Mbps. To be honest, that’s not way off. There may be other discrepancies, such as the test results being given for v6 and measurements done on v7. This they should specify next to the results!

In general, Mikrotik gives more benchmark data than other manufacturers usually do. (Of course this only reflects my limited experience. And of course if a box is specifically designed for a single purpose, such as a CGNAT box, then it is quite natural that it would have more detailed information specifically about its intended application.)

I would much welcome Mikrotik to add some other scenarios to its test results. One example that often comes up is wireguard.

Specifically for NAT I don’t see much point, because this is already well covered by the 25 filter rules scenario; the mere act of rewriting the addresses is really cheap compared to connection tracking. Of course I would welcome fast track results :slight_smile:

4

looks like a candidate scenario for fast-track config (of course, properly configured)

5

Yes, the hEX S would be the one You want, given the constraints.
Take a look at the speed table: Routing, 25 IP rules, 512 byte.
It gives something like Your speed. My guess is You aren’t using fast path, and/or have a heavy firewall.

The hEX PoE is a little bit faster than the hEX, and my hEX did get 940 Mbps with NAT and PPPoE, on Speed Test. But I had a very simple firewall and used fast path. These smaller routers really need fast path to shine.