Nice, thanks!
Can’t wait to see Block Diagram for this device!
If you mean the hAP be³ then it's already available on the website:
Wow, must be the most recent update, been checking for it occasionally!
PS USB to SD controller looks suspicious. SD cards (unlike USB sticks) usually come performance rated.
Wounder if MT would provide any suggestions for storage options for this device.
And IPsec test results are yet to be seen
(sorry for off-top)
Sorry I don't get your point?
USB 3.x shouild have enough speed/bandwidth for a SD card, or you mean something else?
The IPsec numbers were available yesterday, but they have now removed all the benchmark results. You can still see them in the internet archive.
About 10% lower than the hAP ax³ numbers.
I meant that SD card may have different bus it’s connected through. It would be helpful to know which rating\spec\capacity is supported, and thus, would SD or USB still achieve the best performance. (I know that for container apps that’ll probably irrelevant)
@CGGXANNX My gosh you’ve been serious about this)
Numbers (if correct) are not much impressive tho, AX3 did the same (or better)
Any *PON OLT products planned, to escape the high-risk vendor lock-in? Networks used to be about open standards (almost anything connected to anything else should work), this is the opposite - having to buy extra licenses to enable third-party devices etc.
nray gen2 - still 802.11ad not 802.11ay? Is this for PtP only, or where is the matching PtMP sector? Or should PtMP be built on the same wAP60G AP (the newer CubeSA “pro” has much worse latency and jitter, the same newer clients work much better with the old sector)? Lost all hope for the once-hyped “Terragraph” thing, but supporting more than 8 stations per sector would be really useful. UBNT Wave can do max 31, but is expensive and another proprietary vendor lock-in (no one else makes radio-compatible devices) even though seemingly based on 802.11ax and 802.11ay standards.
Id love if the map ax USB port could be useful for either upstream or downstream USB (or both?)
So we could either connect the map ax to a computer (management via USB?) or we could connect a USB device to the map
In my case invariably WiFi, at a hotel or even in a person’s home should I be staying there. Depending on travel circumstances (how much kit I want to carry) I use either a mAP Lite or else an ax2 where 2.4GHz is upstream and 5GHz downstream, so upstream is always 2.4. The mAP ax combines those capabilities of small size, computer or battery powered, separated up and down networks (rather than the down end being virtual) so no need to plug in an ethernet cable to scan and select the upstream.
A42GO-HbeP - When I saw the optical port I was hoping it'd be XGS-PON since that's what we use for our PON customers (ISP). Too bad this model will be GPON but if it's successful, hopefully MikroTik will consider an XGS-PON variant, and just maybe some OLT options too!
mAP ax - I noticed this in another thread earlier today and think it'll be a handy "on-the-go" product that I plan to grab when it comes available (to replace the mAP Lite that I keep in my backpack currently). I wish it had a second copper gigabit port like the bigger mAP but this still appeals to me as-is.
hEX Pro - Oh man, I was excited when I got to this one. I'd love to be able to use these as a service delivery device for my company's commercial DIA customers, but after considering it for a moment, I realized this probably won't do multi-queue shaping in hardware like the CRS3XX switches do and that won't work for my use case. Sure I could use software queues instead but that wouldn't be line rate. There's always the possibility that hardware ingress policing will work correctly on these but I have my doubts since it's been broken on all the other models I've tested. Still, I look forward to getting my hands on some of these so I can experiment with them in my lab!
...
All in all, I'd say these are some compelling new products. Way to go, MikroTik! 
just ask AI about IPQ-9570 hardware nat / offload:
We need to provide a response about IPQ-9570 hardware NAT. The user asked in English, but the previous answer was in Chinese. The user likely wants information in English. We should give a concise, factual answer about IPQ-9570 hardware NAT capabilities.
Based on the earlier Chinese response, we have:
IPQ-9570 is a Qualcomm chip for networking.
It has hardware NAT acceleration via PPE (Packet Process Engine).
Unlike previous IPQ-80xx series, it does not have a separate UBI core for offloading complex protocols like PPPoE/VLAN; these are handled by ARM cores.
It still provides hardware NAT for basic forwarding.
Performance: possibly not as optimized for high connection counts with complex encapsulation as previous generation, but sufficient for typical use.
We should also note that hardware NAT is a common feature in modern SoCs for routers.
We can structure the answer:
Introduction: IPQ-9570 includes hardware NAT acceleration.
How it works: uses PPE (Packet Process Engine) to offload connection tracking and forwarding.
Comparison with previous generation: IPQ-80xx had UBI core for deeper offload; IPQ-9570 relies more on CPU for complex protocols, but still accelerates basic NAT.
Performance implications: For typical broadband (Gigabit), hardware NAT works well; for very high connection counts with PPPoE/VLAN, may use more CPU.
Conclusion: hardware NAT present and functional.
We'll keep it concise and in English.
The Qualcomm IPQ-9570 is a Wi-Fi 7 networking chipset that includes hardware NAT acceleration as part of its packet processing engine (PPE). Here’s a breakdown of its capabilities:
Hardware NAT Engine: The IPQ-9570 integrates a Packet Process Engine (PPE) that offloads connection tracking, NAT, and basic forwarding from the CPU cores, enabling line-rate throughput with minimal CPU load.
Architectural Shift: Unlike the previous IPQ-80xx series (which featured a dedicated UBI core for offloading complex encapsulations like PPPoE and VLAN), the IPQ-9570 handles such protocols primarily in software on the powerful ARM CPU cores. This means deep protocol offloading is reduced, but basic hardware NAT remains fully supported.
Performance: For typical home and SMB use (e.g., Gigabit internet routing, NAT, firewall), the hardware NAT works efficiently. However, in scenarios with extremely high connection counts combined with complex encapsulations (e.g., PPPoE + VLAN + many concurrent flows), the CPU may need to handle more processing than on previous generations, potentially impacting peak performance under those specific conditions.
Use Cases: Ideal for high‑throughput routers, mesh systems, and gateways where basic NAT and routing are the primary tasks, and CPU cores are available for other functions (e.g., advanced QoS, VPN, or containerized applications).
In summary, yes, the IPQ-9570 supports hardware NAT, and it delivers robust performance for most real‑world applications, though its design philosophy emphasizes flexibility and CPU‑driven processing over specialized offload engines.
If the AI did not invent stuff, then the hEX Pro will probably have the "switch chip" classified as IPQ-PPE in RouterOS (like hAP ax²/ax³, Chateau ax, cAP ax). And RouterOS right now doesn't seem to know how to use any of the hardware acceleration features for that yet, even the L2 switching is software only.
The more I read about the Alta Labs Route10, which is more or less comparable to the rb660 (same SoC, ports, etc.), the more it seems that there is no real hardware switching happening. Given that, and the fact that the current “IPQ PPE” implementation from Mikrotik is essentially just a path to the CPU, my expectations that the rb660 will provide any meaningful level of hardware switching, including VLAN support, are not particularly high.
State of IPQ-PPE implementation:
That said, I can still see a lot of potential uses for it, just not as a switch.
I use a hAP ax lite LTE6 but my usage case is a little different - outdoor events. I’ve used it with a battery pack, never tried from a computer. It’s not obvious from the Mikrotik specification that it can be battery powered unless you make the mental leap of the USB-C power connector.
As soon as I read about USB-C the first thing I thought was “good, we can just plug it on the notebook”. The second one was “how much time would a power bank give me?”
I’ve got a PAIDASHU 22.5W 27000mAh power bank and it powers the hAP ax lite LTE6 for a couple of days. Happen to have it on the bench right now, will test it.
There’s a reason both Ubiquiti and MikroTik moved/are moving away from the Qualcomm 60GHz chipsets used in Gigabeams and wAP60’s, Cube60’s, etc. The Peraso chipset is much better in so many ways, especially the 32 client limit.
As for compatibility, no 60GHz vendor (in this space) makes anything compatible with anybody else, so that’s a moot point. That said, you can connect Tachyon 30X radios to Ubiquiti Wave AP’s and it’ll work. The AP doesn’t show it in the GUI, and if you change AP settings, the clients won’t follow. It works great in a pinch but isn’t a long term solution.
Ubiquiti has a custom timing module to handle the greater distances Wave supports, which is probably why they’ve capped CPE limit at 31.
Both Ubiquiti Wave and Tachyon are amazing products. Expensive is relative to the use case. Tachyon for short range does 2.5Gbps at ~$350/side (depending on chosen antenna). Wave Pro can do 1.2-2.7 for $600/side at greater distances. My 80GHz 2Gbps radios cost me $3500 new, nearly 3x the price of a pair of Wave Pro’s.
I would love to see MikroTik do some PTMP with Peraso. Router OS with OSPF and VXLANs in each radio could make for a nice meshing setup.
They also show a new 2.5G switch in RB5009 form factor: https://box.mikrotik.com/f/737d4ca9deb2454d9f2b/?dl=1
Oh my ..!
Finally.
