Is there a faster way to do NAT ?

This is just some out-of-the-box thinking. I don't know if this is even feasible - but here are my rough thoughts ...

- A very basic Mikrotik NAT router ( with two ethernet interfaces doing NAT. )

- Bridge WAN - add ether1
- WAN ( dhcp client )

- Bridge LAN - add ether2
- LAN ( static IP 192.168.0.1/25 )

- DHCP Pool & server ( 192.168.0.0 -through- 192.168.0.127 )

Rather than using -->
/ip firewall nat
add action=masquerade chain=srcnat
To instead use a deterministic NAT or a NAT444 or something similar to a CGN-NAT

Is there a faster NAT throughput configuration possible that uses deterministic NAT ?
Where the Live IP and ports used for deterministic NAT are from the WAN IP address and uses the upper half of the 65,535 ports.
to achieve something similar to this ?

192.168.1.0 ( Natted to WAN Ip address ports 32,000 -through- 32,249 )
192.168.1.1 ( Natted to WAN Ip address ports 32,250 -through- 32,499 )
192.168.1.2 ( Natted to WAN Ip address ports 32,500 -through- 32,749 )
192.168.1.3 ( Natted to WAN Ip address ports 32,750 -through- 32,999 )

192.168.1.4 ( Natted to WAN Ip address ports 33,000 -through- 33,249 )
192.168.1.5 ( Natted to WAN Ip address ports 33,250 -through- 33,499 )
192.168.1.6 ( Natted to WAN Ip address ports 33,500 -through- 33,749 )
192.168.1.7 ( Natted to WAN Ip address ports 33,750 -through- 33,999 )

192.168.1.8 ( Natted to WAN Ip address ports 34,000 -through- 34,249 )
192.168.1.9 ( Natted to WAN Ip address ports 34,250 -through- 34,499 )
192.168.1.10 ( Natted to WAN Ip address ports 34,500 -through- 34,749 )
192.168.1.11 ( Natted to WAN Ip address ports 34,750 -through- 34,999 )

192.168.1.12 ( Natted to WAN Ip address ports 35,000 -through- 35,249 )
192.168.1.13 ( Natted to WAN Ip address ports 35,250 -through- 35,499 )
192.168.1.14 ( Natted to WAN Ip address ports 35,500 -through- 35,749 )
192.168.1.15 ( Natted to WAN Ip address ports 35,750 -through- 35,999 )
- repeat steps to -
192.168.1.124 ( Natted to WAN Ip address ports 64,000 -through- 64,249 )
192.168.1.125 ( Natted to WAN Ip address ports 64,250 -through- 64,499 )
192.168.1.126 ( Natted to WAN Ip address ports 64,500 -through- 64,749 )
192.168.1.127 ( Natted to WAN Ip address ports 64,750 -through- 64,999 )

I have used some Mikrotik routers with NAT-444 ( CGN-NAT ) and found they were far faster and much more customer reliable than regular NAT during fast heavy throughput loads.
So , I am wondering if there if a configuration possible to Nat a /25 and end up with much faster throughput ( using only the WAN dhcp-IP-address * and survive a reboot that gets a different WAN dhcp address ).

FYI - I am aware that the use of 250 ports limits each natted client device to 250 connections to a single remote device --- however there is NAT overflow which permits those 250 ports to also be used again to a different remote device at the same time.

I'm looking for a config that will help a slow mikrotik NATting router to deliver faster throughputs - such as when a NATted client performs a www.speedtest.net
In my LAB , I have a Hex PoE connected to a 1-Gig network. the Hex PoE has a slow CPU and only reaches about 250 to 280 Meg - but a different much faster Mikrotik can allow the same PC to hit near Gig nat speeds.

North Idaho Tom Jones

My understanding is that this is in fact exactly what "action=netmap" does.

I have not, however, benchmarked it against "action=masquerade" or action="src-nat". I suspect any improvement in performance would be negligible, since I'm pretty sure most of the CPU being taken up by NAT involves 1) processing NAT rules until a positive match has been made or all rules have been exhausted (so the longer your firewall and/or NAT rule list, theoretically the more CPU it takes), and 2) connection tracking.

I don't see how connection tracking could be entirely eliminated even in this scenario. Since there isn't an exact 1-to-1 count of available TCP & UDP ports between the smaller number of public IP(s) and the larger number of private ones, and since a LAN host sitting behind the NAT & initiating a connection to the outside world can theoretically pick any number 1024-65535 as a port # to source from, you won't know what port # on the LAN host to map responses back TO until the socket has been opened. So you still need to track that, and you still need to allocate a WAN port and create that mapping at the time of connection anyway. The only way to conceivably eliminate the need to track would be if (to take your example) you mapped ports WAN 32,000 through 32,249 to the *exact same ports* on LAN IP 192.168.1.0, etc., or maybe at least always map the WAN-side ports to the same set of LAN-side ports on each host (so WAN-side 32,000 - 32,249 to 2,000 - 2,249 on 192.168.1.0, WAN-side 32,250 - 32,499 to 2,000 - 2,249 on 192.168.1.1, etc.). And there's no way to guarantee or enforce that a client limit its source ports to those specific narrow ranges, so a NAT implementation that did that would surely break most traffic for most clients.

If using actual RouterBOARD hardware, Fasttrack seems to improve performance and drop CPU utilization by a pretty substantial amount anyway.

My understanding is that this is in fact exactly what "action=netmap" does.

I have not, however, benchmarked it against "action=masquerade" or action="src-nat". I suspect any improvement in performance would be negligible, since I'm pretty sure most of the CPU being taken up by NAT involves 1) processing NAT rules until a positive match has been made or all rules have been exhausted (so the longer your firewall and/or NAT rule list, theoretically the more CPU it takes), and 2) connection tracking.

I don't see how connection tracking could be entirely eliminated even in this scenario. Since there isn't an exact 1-to-1 count of available TCP & UDP ports between the smaller number of public IP(s) and the larger number of private ones, and since a LAN host sitting behind the NAT & initiating a connection to the outside world can theoretically pick any number 1024-65535 as a port # to source from, you won't know what port # on the LAN host to map responses back TO until the socket has been opened. So you still need to track that, and you still need to allocate a WAN port and create that mapping at the time of connection anyway. The only way to conceivably eliminate the need to track would be if (to take your example) you mapped ports WAN 32,000 through 32,249 to the *exact same ports* on LAN IP 192.168.1.0, etc., or maybe at least always map the WAN-side ports to the same set of LAN-side ports on each host (so WAN-side 32,000 - 32,249 to 2,000 - 2,249 on 192.168.1.0, WAN-side 32,250 - 32,499 to 2,000 - 2,249 on 192.168.1.1, etc.). And there's no way to guarantee or enforce that a client limit its source ports to those specific narrow ranges, so a NAT implementation that did that would surely break most traffic for most clients.

If using actual RouterBOARD hardware, Fasttrack seems to improve performance and drop CPU utilization by a pretty substantial amount anyway.

Thanks for the reply.
If I remember correctly , on my Mikrotiks and VyOSomething CGN-NAT routers ( where those CGN-NAT routers use a live IP non-WAN-address instead of WAN-ip-address );
If a customer computer gets an ip address of 192.168.0.10 , then outbound traffic and all 65,535 ports would be CGN-Natted ports 34,500 -through- 34,749 . Which results in a remote located internet server seeing all connections from the this customer LAN PC coming from the live IP address with originating ports from 34,500 -through- 34,749 .

On my production CGN-NAT 444 routers , I found everything was much faster than normal nat and much more stable - thus got me to wondering if there was a faster nat method to do the same but only using the WAN IP address.

On my CHRs , changing from Nat-44 to Nat-444 increased my sustained throughput from about 2-3 Gig up to 4-to-7 Gig ( and my customers really noticed the huge speed increases and tech calls re nat & Internet connections to anything went almost to zero ).

note - by larger CGN-NAT / Nat-444 routers handle about 800 customers with thousands of devices. What I'm looking ( and trying to make faster ) is a single nat router at a customer location that may have about up-to 50 devices on their home network. If it works , then repeat the config for other customer home located routers.

If a customer computer gets an ip address of 192.168.0.10 , then outbound traffic and all 65,535 ports would be CGN-Natted ports 34,500 -through- 34,749 . Which results in a remote located internet server seeing all connections from the this customer LAN PC coming from the live IP address with originating ports from 34,500 -through- 34,749 .

Correct. My point is, when your example 192.168.0.10 host chooses (say) TCP port 57243 to initiate a new outbound connection from, HOW is it decided which WAN port between 34000 - 34749 this outbound connection is mapped to?

I think what you are suggesting is that CPU performance can be lowered and NAT forwarding performance can be higher if it is made to be more "stateless". This argument makes sense. But you still have to answer the question, when you have more available ports on one side than the other, how do you eliminate the tracking of any "state"?

The most obvious and simple method that the NATting device is likely going to use to solve this is by looking at what ports between 34500 - 34749 aren't already being used (mapped to another active traffic flow), and then pick the next available one. So maybe 34502 is the next available unused TCP port (192.168.0.10 might already have 2 other active TCP connections that it made prior to the one it is using with local source port 57243 from my example above). Now it has to *remember* that mapping. That's what connection tracking is for.

At first, it occurs that conceivably one way of eliminating the need to track any connection state would be if it just statically maps each WAN-side port # to each LAN-side port # sequentially, but continually "wraps around" the available port #s on the WAN-side. So, for example, 4500 on the LAN-side always maps to 34500 on WAN, all the way up through 4749 to 34749, then 4750 loops back around to 34500 again, and so on. But this has two problems I think: 1) What if the LAN host decides to open connections from both 4500 and 4750, simultaneously? Now you have a TCP port collision on the WAN-side. 2) You actually still will need to track state, since when a response comes back from an internet host on the WAN-side to 34000, how does the NATting router know WHAT port on 192.168.0.10 to direct that response to (if it could potentially have been 4500, 4750, 5000, 5250, 5500, etc.)?

re: ... example 192.168.0.10 host chooses (say) TCP port 57243 to initiate a new outbound connection from, HOW is it decided which WAN port between 34000 - 34749 this outbound connection is mapped to? ...

Pretty much the same way regular normal nat works but the port and IP address are both re-mapped.

Pretty much the same way regular normal nat works but the port and IP address are both re-mapped.

Then it's not stateless, and thus it's not really saving you any CPU cycles.

I don't see where you think the CPU savings are coming from with the change you are suggesting.

re ... 34000 - 34749 aren't already being used (mapped to another active traffic flow) ...

But those ports can be re-used when a customer is connecting to a different computer or multiple different remote remote servers at the same time - this is normal nat overflow

- also note
when I configured my core CGN nat routers to nat-444 from normal nat-44 , the cpu loads on my core nat devices went down between 30 to 50 percent or more.

edit - note , when I configured nat-444 , I used a ton of jump tables to optimize the /21 CGN-nat.
( 1/2 , 1/4 , 1/8 , 1/16 , 1/32 ) which resulted in fewer nat lookups sequential steps when traffic was inbound to the customer. Each jump table starting out at a /21 location had eight possibilities , repeating the procecure all the way down in jump tables to 8 IPs for the CPU to walk through.
edit note - on my Mikrotik CHR routers doing 8 live IP address to a full /21 natted interface required several thousand ( around 40-k ) lines of configuration lines of jump tables. My VyOSomething routers doing the exact same nat and same fw jumps used less than 100-lines of config.

edit - note , when I configured nat-444 , I used a ton of jump tables to optimize the /21 CGN-nat.
( 1/2 , 1/4 , 1/8 , 1/16 , 1/32 ) which resulted in fewer nat lookups sequential steps when traffic was inbound to the customer.

Yeah that part make sense: each rule executed is uses CPU and adds [marginal] latency.

I've never test it, but my hunch be "masquerade" be good to avoid. If WAN IP changes, it has to traverse/parse/remove connection tracking & not sure of it's internal logic on check if IP is changed, etc., etc. Basically masquerade "does more stuff", whether its significant IDK but it "heavier" than a src-nat.

I don't know if we are managing to talk past each other, or what.

You keep mentioning NAT444. My understanding of the theory behind NAT444 (which perhaps is wrong) is that *something* is still taking up the majority of the connection tracking workload. It's just that if you are having the customer CPE/router doing NAT, you can have it configured to restrict the ports that it uses on its WAN-side to a matching number of ports that your CGNAT device will map that customer's traffic to. Hence, the big ISP-side CGNAT gateway itself doesn't need to be burdened with tracking all of that state...you are offloading/distributing all of that connection state tracking burden to all of the client CPE devices. But SOMETHING still has to do it, somewhere. (And you can only get away with this if 100% of the CPE are under your control.)

If you are thinking that you can potentially collapse a NAT444 setup into a single NAT44 setup and yet still reap all of the CPU-saving benefits on the singular NATting gateway...I'm still not clear on how you think that could work? I'm getting "perpetual motion machine" vibes here, heh.

There Ain't No Such Thing As A Free Lunch (TANSTAAFL), after all.

In my LAB , I have a Hex PoE connected to a 1-Gig network. the Hex PoE has a slow CPU and only reaches about 250 to 280 Meg - but a different much faster Mikrotik can allow the same PC to hit near Gig nat speeds.

I still don't understand why you don't just implement Fasttrack. You can achieve near-gig NAT speeds with Fasttrack on a hEX PoE.

In my LAB , I have a Hex PoE connected to a 1-Gig network. the Hex PoE has a slow CPU and only reaches about 250 to 280 Meg - but a different much faster Mikrotik can allow the same PC to hit near Gig nat speeds.

I still don't understand why you don't just implement Fasttrack. You can achieve near-gig NAT speeds with Fasttrack on a hEX PoE.

On my Hex Poe , I have enabled Fasttrack. Got some increase but not a huge amount.

Pick this up tomorrow ...

I still suspect there has got to be a method to configure a customer located Mikrotik router to do CGN-NAT ( NAT-444 ) with fw jump tables ( using the WAN IP address ) , and get much faster throughput when compared to Mikrotik's normal NAT.

Hope I'm not beating a dead horse ...

North Idaho Tom Jones
- going home now ...

On my Hex Poe , I have enabled Fasttrack. Got some increase but not a huge amount.

I would be interested in seeing the config. I have personally tested Fasttrack vs. non-Fasttrack on RB951G, which has slower and older CPU in it than hEX PoE does, and can confirm I get results very close to what MikroTik boasts on their Fasttrack page (which uses an RB2011, which has exact same CPU in it as 951G does):



Disclaimer: last time I benchmarked Fasttrack, I did it on ROS 6.x. I have not actually re-run these tests on 7.x on the same hardware. Perhaps I should do that...

In any case, this is the result I got when I tested this on the 951G last time.

Without Fasttrack:



With Fasttrack:



Since I got over twice as much throughput on my lab 951G than you did even without Fasttrack on your lab hEX PoE, it makes me think that something else is going on here... (or maybe you are testing with 7.x, and firewall/NAT performance as a whole has gotten worse on 7.x? ...not impossible!)

I still suspect there has got to be a method to configure a customer located Mikrotik router to do CGN-NAT ( NAT-444 ) with fw jump tables ( using the WAN IP address ) , and get much faster throughput when compared to Mikrotik's normal NAT.

By definition, you can't have "NAT444" without two layers of NAT (4-to-4, then 4-to-4 a second time). Putting that aside, I'm still not exactly sure what you are proposing or how it's going to improve performance. If you are thinking that going from a single rule to multiple rules chained together with jumps is going to improve performance, I am very skeptical. The particular NAT "action" that you are using with multiple rules would have to be worlds more efficient than the single rule that I presume you are already using, and I just don't see that as being likely.

edit - note , when I configured nat-444 , I used a ton of jump tables to optimize the /21 CGN-nat.
( 1/2 , 1/4 , 1/8 , 1/16 , 1/32 ) which resulted in fewer nat lookups sequential steps when traffic was inbound to the customer.

Yeah that part make sense: each rule executed is uses CPU and adds [marginal] latency.

For sure "less" rule look-ups is better than "more". But it just begs the question, what exactly is being compared to what? When I read what he wrote, it sounded like he was saying that he implemented CG-NAT one way, it was slow, so he improved performance with the jump tables. Okay, fair enough. But assuming I'm reading him correctly, I think he thinks that if he simply applies a similar strategy to the NAT config of a simple residential gateway, he can reap similar performance improvements. That just doesn't follow, since you are comparing apples to oranges when pitting a CGNAT appliance to a dinky consumer router. More specifically, if you are already down to ONE NAT rule...how is multiplying them but then adding jump tables supposed to make up for going from 1 rule to >1 rule, exactly? The only way to make up the difference is if "action=masquerade" for example (assuming that's even what he is using at the moment in his lab tests) is WAY more inefficient than whatever other action he would use in this hypothetical new-way-to-do-NAT. I don't buy it...but would be happy to be proven wrong.

I've never test it, but my hunch be "masquerade" be good to avoid. If WAN IP changes, it has to traverse/parse/remove connection tracking & not sure of it's internal logic on check if IP is changed, etc., etc. Basically masquerade "does more stuff", whether its significant IDK but it "heavier" than a src-nat.

I have never noticed "action=masquerade" to result in measurably less performance than an equivalent "action=src-nat, src-address=<WAN IP>", though like you I haven't sat down to rigorously test it (I've never had reason to). My understanding is that "action=masquerade" is basically identical to "action=srcnat" but where src-address is picked up for you from the address assigned to the egressing interface. In fact, if you have multiple interfaces that you need to NAT traffic out of, you can likely find a way to address all of them with a *single* "masquerade" rule (just don't match on out-interface, or add all interfaces to a list and match against the interface list!), versus multiple separate src-nat rules, so if anything, "masquerade" not only results in simpler config, but potentially better performance due to fewer rules! If your theory about what extra work it is needing to do to prune the contents of the connection tracking table if the IP ever changes is accurate, I would think that should only cause a slowdown whenever such a change happens, not perpetually for all traffic flows at all times.

Again, happy to be proven wrong on any/all of this... and I'll try to dedicate some time to labbing up a few scenarios to see if I can get some data to either back or contradict these assumptions.

EDIT -- EDIT -- EDIT:

I just saw one of your edits to an earlier post, where you said this:

edit note - on my Mikrotik CHR routers doing 8 live IP address to a full /21 natted interface required several thousand ( around 40-k ) lines of configuration lines of jump tables.

40,000+ NAT rules??? Yikes! I understand it's skipping and jumping a lot, but I still have to think that is going to take its toll.

How many lines/rules did you have in your previous RouterOS CGNAT config without your jumps?

I just found your older post describing your config over here on this thread.

First, all that NAT444 means is just that there are two layers of NAT44 back-to-back. This means there are two NAT gateways. This is referring to the customer CPE doing NAT (so for example 192.168.1.0/24 to a single 100.64.x.x IP on the customer WAN), and then to your CGNAT appliance doing NAT a second time (from the customer 100.64.x.x to your public IPs).

So, technically, you are doing "NAT444" just by having a CGNAT box, regardless of how it is configured.

Often NAT444 is a term used in the context of CGNAT for obvious reasons, but has picked up additional meaning over time, because if you can limit the port#s that the customer router uses, then you can do precise, stateless 1-to-1 mapping of ports on your CGNAT gateway. Then you don't technically need to do connection tracking on the CGNAT box. So for example, if you configure customer A router to limit its NAT of 192.168.1.0/24 to WAN 100.64.1.1 ports 5000-5250, and customer B router to limit its NAT of 192.168.1.0/24 (separate LAN) to WAN 100.64.1.3 ports 5250-5500, then your CGNAT box just knows that 5000-5250 on a specific public IP always belongs to customer A (100.64.1.2), and 5250-5500 on the same public IP always belongs to customer B (100.64.1.3). Then traffic flowing in both directions through the CGNAT box can have both IPs and port#s re-written without consulting a connection tracking table at all. That will allow you to reduce your CPU usage and increase the scalability of your CGNAT *considerably*, because all of the little residential/customer routers are doing all of the connection tracking for you, and the CGNAT box can then do zero.

Unfortunately, RouterOS doesn't support this kind of static, connection-tracking-less IP+port mapping (as far as I can tell). Even if they did, to make use of it requires that you have absolute control over *both* NATs that are happening (not just your CGNAT box, but also 100% of customer routers), such that you can precisely control the port numbers that are used end-to-end through your network, all the way down to the customer router...that way, the core CGNAT box and all of your customer routers can be working in tandem to scale up the efficiency and performance of your CGNAT.

Second, I don't think you need all of that jump table craziness in order to achieve NAT that is equally as performant as what you are getting right now. You can achieve this by switching to "action=netmap" instead.

I understand one of the requirements is that when you get a subpoena or DMCA notice, you need to be able to trace back to a specific customer from the public IP and port#. Both this and short NAT rule lists are possible using "action=netmap". You use of jumps is just a workaround for the way that "src-nat" usually works. But "action=src-nat" is not the correct tool for the job in this case.

Mapping a /29 to a /21 is a 256-to-1 ratio of private-to-public IPs. That's quite a high ratio. The lower the ratio, the fewer NAT rules you can get away with of course.

Anyway, with "netmap", you only need as many rules as you need private IPs mapped to one public IP. This is true regardless of how many total private and public IPs you have...it's only the ratio we care about. With a 256-to-1 ratio, you only need 513 rules: 256 rules for TCP traffic, 256 rules for UDP traffic, and one rule at the end for "catch-all". I have been testing this myself over the last few weeks, and performance seems quite good so far (right now playing with about 300,000 tracked connections and ~5-6Gbit/s of traffic running bare-metal on an old i5-9500, but with a NAT private-to-public ratio of 64:1...the PC hasn't reached its limit and the CPU is not peaking out; however, I have also tested a CCR1036-2S+ and it seems to be able to handle considerably more).

I have attached an example that maps 100.64.0.0/21 to the fictitious 200.200.200.200/29. Just search-and-replace 200.200.200.200/29 with your block of 8 (and of course add whatever other matchers are relevant to you, like out-interface etc.). In this example, traffic seen coming from 200.200.200.200:1024-1275 would have come from 100.64.0.0, seen from 200.200.200.201:1024-1275 comes from 100.64.0.1, etc.

Brief follow-up: After only looking for a couple of minutes, I wasn't able to round up a hEX PoE or a hAP ac (which has very similar CPU to hEX PoE) to run some really quick tests with. I'm sure we have some around here somewhere so I will look more deeply later for an available one. But I did find an old 951G, so I ran some basic 6.x vs. 7.x, "masquerade" vs. "src-nat" vs. "netmap", and Fasttrack vs. No-Fasttrack tests on it.

First, as I predicted before, when using a single NAT rule and no Fasttrack, "masquerade", "src-nat", and "netmap" actions were all just as equally performant as each other. Zero throughput boost observed when switching from "masquerade" to something else, and no throughput degradation when switching back to "masquerade".

6.x *does* perform better than 7.x does, when you are not using Fasttrack. I can get almost 500 megs of NAT throughput on 6.x with just straight IPoE, and about 350 megs with a PPPoE client thrown in the mix @ 1440 MTU. On 7.x, this falls down to about 200 megs. I did a little playing around in 6.x again after that, and discovered it also falls down to about 200 megs if you disable the Route Cache. The route cache is gone in the newer Linux kernels, so that would seem to explain the throughput drop-off there in 7.x.

On both 6.x and 7.x, I can get 850-900 megs of NAT throughput on the lowly RB951G when using Fasttrack, no problem, even with PPPoE and lower MTU. If you aren't able to replicate this on your hEX PoE (with an even more powerful CPU than my 951G), then I'd bet something else weird is going on with your config. Maybe do "/system/reset-configuration no-defaults=yes" on it, re-configure it with BARE minimum (WAN and LAN IPs, the single NAT rule, and the two Fasttrack filter rules taken from MikroTik's "initial configuration" example), and re-test. If you are now suddenly able to get a gigabit of NAT throughput on your hEX PoE this way, then start adding back other parts of the config that were there before, until the performance drops again.

OK - so now I have some faster nat speeds.

In my prior posts in this topic , I was using a Hex-Poe
I now also have some Hex-S routers.

My head-end network facing these client Mikrotik devices ( Hex-PoE and Hex-S ):
- Adtran TA-5000 ( GPON --- 2.4-Gig to customer and 1.2-Gig from the customer ).
- about 16+ other customers on this shared GPON port facing customers on this GPON port ( single strand fiber ).
Note; GPON uses a single fiber to multiple GPON connected customers.
Note; An ISP may have dozens/hundreds of GPON ports. Each GPON single fiber from the ISP port is then connected to a remote neighborhood located optical-splitter ( think of a switch that does not use any power/electricity ). The optical-splitter then has 8 or 16 or 32 or 64 out ports. Each port from an optical-splitter is then connected to a remote GPON customer. (( Thus - an ISP with a single GPON port can be connected up to 64 remote fiber GPON customers )).

My test remote client router that connects to my ISP via GPON.
- Mikrotik Hex-PoE ( and now also I have a Hex-S ) ROS-Version 7.18.2
** No bridges configured ***
Interface sfp1 ( renamed to WAN ) ( IP DHCP Client ) (( FS sfp module " GPON-ONU-34-20BI " inserted in the sfp port.
Interface ether1 ( renamed to LAN ) ( DHCP server to the customer over this ethernet )

The following fasttrack configurations added to the the client Mikrotik:
/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related
/ip firewall filter add chain=forward action=accept connection-state=established,related

My Hex-S can now download and upload at a full 1-Gig ( using remote speed test sites: speedtest.net and fast.com )
My Hex-PoE can now download and upload around 500-Meg+

Notes:
- In my previous posts in this topic , I was ether not using fasttrack - or had it wrongly configured.
- In my previous posts in this topic I was using the following:
- - Bridge WAN with interface sfp1 as a port on the WAN bridge ( WAN was IP dhcp client )
- - Bridge LAN with interface ether1 as a port on the LAN bridge ( LAN was DHCP server )
* All traffic was : GPON-to sfp1 , sfp1 was a port on the WAN bridge. LAN bridge had ether1 as a port on LAN bridge. Customer connected to ether1. (( all IP addresses were on on bridge WAN or bridge LAN -and- all customer traffic was going through the two bridges WAN and LAN )).

In all of my tests , I found that not using any bridges and no ports on any bridge , my speed tests results were always faster.
Also with fasttrack properly configured , everything was much faster.

So , using both fasttrack -and- no bridges are what got my remote Mikrotiks connected via GPON running fast ( Hex-S now hitting 1-Gig up/down ).

Hmmm -- next , I want to try the same test configuration with a remote GPON connected Mikrotik what has a 10-Gig sfp+ port. I suspect I should be able to then hit up to 2.4-Gig down and up to 1.2-Gig up speedtest results.

North Idaho Tom Jones

EDIT - update notes:
Using a 2'nd Mikrotik router ( RB4011iGS+5HacQ2HnD ) that is on the LAN side behind my GPON connected HeX-S NAT router , I performed a Mikrotik Speed-Test to one of my external Mikrotik btest servers ( six L3 routing hops ) and got the following results:
TCP-Download: 933Mbps local-cpu-load:54%
TCP-Upload: 934Mbps local-cpu-load:27% remote-cpu-load:21%
So yea , the Hex-S as a Nat router can easily NAT at Gig speeds ( almost wire speed ).

In my prior posts in this topic , I was using a Hex-Poe
I now also have some Hex-S routers.

hEX S is of course way faster, since it has a dual-core + hyperthreaded CPU in it @ 880MHz, while the hEX PoE has a single-core, single-threaded CPU @ 800MHz. So not entirely apples-to-apples comparison.

My Hex-S can now download and upload at a full 1-Gig ( using remote speed test sites: speedtest.net and fast.com )
My Hex-PoE can now download and upload around 500-Meg+

[...]

So yea , the Hex-S as a Nat router can easily NAT at Gig speeds ( almost wire speed ).

With my lab 951G, I have zero problems getting essentially wirespeed NAT with Fasttrack. It has an even older and slower (600MHz) CPU compared to the hEX PoE.

I have since been able to free up a hAP ac for lab testing, which has a virtually identical CPU to the hEX PoE, just clocked slightly slower (720MHz). I can get even better performance on it without Fasttrack than I get on the 951G without Fasttrack. But with Fasttrack, both 951G and hAP ac are equally as fast as each other.

So I am still not sure why you are seeing half the speeds on your hEX PoE with Fasttrack that I am seeing in my own tests.

In all of my tests , I found that not using any bridges and no ports on any bridge , my speed tests results were always faster.

I can confirm that finding. At least without Fasttrack, adding a bridge to the config does impact performance, even if it is only one bridge on the LAN side (and not a second one for the WAN port), and even if there is only one member port of the LAN bridge, and even if that port is hardware-offloaded. Without Fasttrack, I lose about 30% of my forwarding+NAT performance with such a bridge in place, compared to just assigning the LAN IP directly to an ethernet port. (For the record, I believe that when I tested Fasttrack on a 951G a couple of years back when I took those Speedtest.net screenshots, I was not using any bridges, which is I think how I achieved that >500Mbit/s test result without Fasttrack.)

In my most recent tests that I reported on in my previous reply to this thread, I was using a bridge for every test. So when I was getting roughly 200 megs without Fasttrack on a 951G with RouterOS 7, that was with bridge. If I remove the bridge, that number does go up markedly (though still not north of 500).

However, WITH Fasttrack, I find that the existence of the LAN bridge makes no difference and has no negative impact on performance. Even with the LAN bridge, I always get ~900 megs in both directions on 951G / hAP ac / hEX PoE class hardware (single-core MIPS), as long as I have Fasttrack properly configured.

I have also since thrown IPv6 into the mix in the lab, since I wanted to do a head-to-head of IPv4 Fasttrack vs, IPv6 Fasttrack on the latest RouterOS 7 releases where IPv6 Fasttrack was finally introduced. I am extremely happy to report that IPv6 Fasttrack works just as well as IPv4 Fasttrack does, and I get identical IPv6 forwarding performance out of the router that I do with IPv4+NAT: ~900Mbit, both directions, even with a LAN bridge + PPPoE with constrained MTU on the WAN. (IPv6, of course, is not being NATted in this test, though there are the default firewall rules in place, and IPv6 connection tracking is happening.)

I am extremely happy to report that IPv6 Fasttrack works just as well as IPv4 Fasttrack does, and I get identical IPv6 forwarding performance out of the router that I do with IPv4+NAT: ~900Mbit, both directions, even with a LAN bridge + PPPoE with constrained MTU on the WAN. (IPv6, of course, is not being NATted in this test, though there are the default firewall rules in place, and IPv6 connection tracking is happening.)

Good to hear. I wouldn't not have bet on that positive outcome in your IPv6 configuration.

This thread has been a very educational reading

At least without Fasttrack, adding a bridge to the config does impact performance, even if it is only one bridge on the LAN side (and not a second one for the WAN port), and even if there is only one member port of the LAN bridge, and even if that port is hardware-offloaded. Without Fasttrack, I lose about 30% of my forwarding+NAT performance with such a bridge in place, compared to just assigning the LAN IP directly to an ethernet port.

Thanks for testing and sharing. This could be very useful in situations where Fasttrack is not possible. E.g. turning a device into a true "router only" with an external switch (or switches) handling all L2 traffic could provide just enough extra performance to avoid buying something new.