AX3 as basic AP/switch

Two questions please:

  1. How can I confirm that the config below matches what would on this forum be labeled as “used as a switch and not as a router?” (Yes, I know about the other thread: I started it. But, I am asking for the specific config entries below to be identified. For example, the AX3 has an IP, so it fails that test for “used only as a switch,” but the IP address is used for management of the AX3.)

  2. How can I confirm that that the traffic flowing between wifi-connected user and the upstream device (the one that the ax3 is connected to) is going exclusively through the AX3’s switch chip (and not hitting the CPU)?


# 2025-04-22 05:43:10 by RouterOS 7.18.2
# software id = PTUN-M4Y8
#
# model = C53UiG+5HPaxD2HPaxD
# serial number = HEW09xxxx
/interface bridge
add admin-mac=78:9A:18:30:D6:EE auto-mac=no comment=defconf name=bridge \
    port-cost-mode=short
/interface wifi
add channel.band=5ghz-ax .skip-dfs-channels=disabled .width=20/40/80mhz \
    configuration.mode=ap .ssid=ax3 disabled=no name=wifi1 radio-mac=\
    78:9A:18:30:D6:F2 security.authentication-types=wpa2-psk,wpa3-psk
add channel.band=2ghz-ax .skip-dfs-channels=disabled .width=20/40mhz \
    configuration.mode=ap .ssid=ax3 disabled=no name=wifi2 radio-mac=\
    78:9A:18:30:D6:F3 security.authentication-types=wpa2-psk
/interface list
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add comment=OffBridge name=OffBridge ranges=192.168.55.100-192.168.55.200
/ip dhcp-server
add address-pool=OffBridge interface=ether5 name=OffBridge
/system logging action
set 3 remote=127.0.0.1
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=ether3 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=ether4 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=wifi1 internal-path-cost=10 \
    path-cost=10
add bridge=bridge comment=defconf interface=wifi2 internal-path-cost=10 \
    path-cost=10
add bridge=bridge interface=ether1
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes forward=no
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=ether5 list=LAN
/interface ovpn-server server
add mac-address=FE:CD:A0:F7:0F:96 name=ovpn-server1
/ip address
add address=192.168.0.13/24 comment=defconf interface=bridge network=\
    192.168.0.0
add address=192.168.55.100/24 interface=ether5 network=192.168.55.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-server network
add address=192.168.55.0/24 dns-server=192.168.0.11 gateway=192.168.0.1
/ip dns
set allow-remote-requests=yes servers=192.168.0.11,9.9.9.9
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip kid-control
add fri=0s-1d mon=0s-1d name=Monitor sat=0s-1d sun=0s-1d thu=0s-1d tue=0s-1d \
    wed=0s-1d
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.0.11 \
    routing-table=main scope=30 suppress-hw-offload=no target-scope=10
/ip service
set www-ssl disabled=no
/ipv6 nd
set [ find default=yes ] disabled=yes
/snmp
set enabled=yes trap-version=2
/system clock
set time-zone-name=America/New_York
/system identity
set name=355-hAPax3
/system note
set show-at-login=no
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.north-america.pool.ntp.org
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool romon
set enabled=yes id=78:9Axxxx
/tool sniffer
set filter-ip-address=192.168.2.0/24 filter-ip-protocol=icmp

once wifi interface was involved even it has switch chip it will processed by the cpu anyway.

The criteria for a router as mentioned in that other thread are that a device is a router if it needs more than one own IP to do its job.

Why waste a vlan capable device when a flat unmanaged switch will do?

Thanks guys!

I did not know that frames between wifi-connected devices and the devices connected to the etherports required the CPU. I thought if the wifi interfaces were part of the bridge, it would be switch chip only.

“More than 1 IP to do it’s job” captures the criteria nicely.

The ax3 will eventually be set up with VLANs for tagging frames from wifi-connected devices. Learning, which is what I’m doing here, is never a waste.

In addition to what others have said about WiFi always going through the CPU, I also have to disappoint you: hAP ax3 is not a good device if you want wired Ethernet hardware switching while also using VLANs and WiFi. Here is why:

There are two ways to configure VLANs:

  1. Bridge VLAN filtering-but this will disable hardware switching unless the router supports it.
  2. Using the switch chip menu (aka “the old way”).

HAP ax3 has IPQ-PPE switch chip (https://help.mikrotik.com/docs/spaces/ROS/pages/15302988/Switch+Chip+Features#SwitchChipFeatures-Introduction). And based on https://help.mikrotik.com/docs/spaces/ROS/pages/328068/Bridging+and+Switching#BridgingandSwitching-BridgeHardwareOffloading, it doesn’t support offloaded bridge VLAN filtering.

I have a hAP ac2 that also doesn’t support offloaded VLAN filtering. No problem, I just use the switch chip method for VLANs. I don’t use WiFi on my ac2, but when I deployed another ac2 at my relative’s house, I did need to use WiFi. And of course, I wanted the Wave2 wifi-qcom-ac driver.

Here is the twist: with the new drivers (AC Wave2 and AX) the only way to configure VLANs on WiFi is using bridge VLAN filtering. Setting VLAN on wireless interface itself won’t work (like it did with the old pre-AX drivers). It means you must enable bridge filtering, and that will disable wired ports hardware switching on ax2, ax3, ac2, ac3 and others.

For that particular use case this is totally fine, there is no heavy LAN traffic. Even if you have one-two devices with occasional heavy traffic (e.g. from a desktop to a NAS), you probably won’t feel any difference. It helps that ax3 has a very powerful CPU.

I also see this note from the second link about IPQ-PPE (ax3):

6. Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).

This is talking about general bridge hardware offload, different from VLAN filtering. If I read the above correctly, ax3 can’t do hardware switching even if you don’t use VLANs.

Since I don’t own ax3, would you mind posting the output of this command on yours?
/interface/bridge/port/print

That is fascinating!

I just want to make sure I understand: When we say HW offloaded we mean that the frames are processed (I wouldn’t dare say routed) by the switch chip, right? In other words, HW offloading is when the CPU is NOT being used, right?

And, basically, with the ax3, if it is configured with VLANs or with WiFi, there is no HW offloading?

Here is the output:

[admin@355-hAPax3] > /interface/bridge/port/print
Flags: I - INACTIVE
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
#   INTERFACE  BRIDGE  HW   PVID  PRIORITY  PATH-COST  INTERNAL-PATH-COST  HORIZON
;;; defconf
0   ether2     bridge  yes     1  0x80             10                  10  none   
;;; defconf
1 I ether3     bridge  yes     1  0x80             10                  10  none   
;;; defconf
2 I ether4     bridge  yes     1  0x80             10                  10  none   
;;; defconf
3 I wifi1      bridge          1  0x80             10                  10  none   
;;; defconf
4 I wifi2      bridge          1  0x80             10                  10  none   
5 I ether1     bridge  yes     1  0x80                                     none

HW offloading usually means that the device has an ASIC that will process the frames 1000 times faster than the CPU … an ASIC is a special chip whose purpose is to speed up the specialized process incredibly fast … ASIC stand for Application Specific Integrated Circuit

Is ASIC the same as the switch chip?

For the sake of argument: yes.

Yes the switch chip in the case of the model you referenced is a type of ASIC - its very limited to a few functions … a previous poster provided you with a link that details this ASIC’s capabilities … You will note the following MikroTik comment <> Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).

I use my ax3 with vlan filtering and I see no ill effects on my LAN subnets…

… which is done by software/CPU, so no HW offloading. Hence no problems snd high CPU load (but still wirespeed).

I guess I’d say don’t get hung up on these terms. IMO switch/router/“switch chip”/“hardware offload” can be somewhat fuzzy in meaning, especially given newer chip designs that combine even more into less “chips”.

And, IMO start with use case/problem & get the right hardware for the problem. Now, perhaps the problem is you have a lot of hAPax3 in inventory but no dumb switch… so whether it be better to buy new dumb switches, or re-purpose hAPax3 really would depend on business needs.


Run a bandwidth test and compare with “test results”. If those result are close the “test results” on the product pages, that the metric to measure. At the end of day, some features will need CPU, so if you use case needs that feature, there may not a lot to optimize in config…you still need to get the right hardware for expected load.

Thanks for the output, it confirms my suspicion: ax3 (for now?) cannot do switching in hardware regardless of VLANs. Here is output from an ac2 for comparison:

/interface/bridge/port/print 
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
#    INTERFACE  BRIDGE  HW   PVID  PRIORITY  PATH-COST  INTERNAL-PATH-COST  HORIZON
;;; defconf
0  H ether2     bridge  yes     1  0x80             10                  10  none   
;;; defconf
1 IH ether3     bridge  yes     1  0x80             10                  10  none   
;;; defconf
2 IH ether4     bridge  yes     1  0x80             10                  10  none   
3  H ether1     bridge  yes     1  0x80             10                  10  none   
;;; defconf
4 IH ether5     bridge  yes     1  0x80             10                  10  none   
5 I  wifi1      bridge        101  0x80                                     none

The “H” flag next to interface name means the port is hardware offloaded. Yours is missing it. The first line of your output doesn’t even list “H” as an available flag since bridge offloading is disabled. Don’t be confused by the “HW” column and all those “yeses”, it just means the port is configured to enable offloading when it’s available.

It’s a pity that such a decent (in all other aspects) device as ax3 doesn’t have this feature. MikroTik seems to limit the flexibility in some recent devices. So, ax3 is an excellent home WiFi router (I hope so; I don’t use much their WiFi), but a poor switch. If you have heavy wired traffic across the 4 ports, performance will suffer noticeably. The note #6 above implies this will be addressed in the future. However, it still won’t fix the VLAN offloading since it’s just not part of IPQ-PPE chip.

@anav, you are probably correct, 99% of home users won’t really see any difference. If you care to test this out, try plugging in 4 wired devices and then kick off some large file copy from eth2 to eth3, while copying from eth4 to eth5 (assuming eth1 is WAN). My guess is you still might be able to get close to 1 Gbps for both pairs but watch the CPU utilization. There will probably be hardly any cycles left.

While even advanced home users rarely have sustained heavy LAN traffic, if one has decent WAN bandwidth, a long list of firewall rules, some VPN tunnels, maybe some containers—all that takes CPU. Which is why it would be nice not to waste it on simply switching wired ports.

@Josephny, the “good” news is that when you start using VLAN filtering, you won’t see much difference from what you have now. If you have some devices with heavy wired traffic, it would be best to a get a cheap $15 unmanaged switch and put on it all those devices.

Concur, well stated.
Yes, if one has heavy VLAN traffic ( same vlan ) between different ports on the switch, the ax3 whether its a switch or a router will see some slow down in traffic, whereas a proper switch will not.

Great discussion – thank you.

For clarification of one aspect of the origin and intent of my quesiton: I was thinking specifically about whether frames between wifi and etherports could exclusively use the switch chip. That is, the use of a dumb switch would not be applicable.

Right, the above limitation only affects LAN to LAN traffic within the same VLAN. Everything else always goes through the CPU anyway:

  1. Between wireless and LAN.
  2. Between wireless and wireless.
  3. Between wired and wired in different VLANs, with the exception of some higher-end switches that support L3 inter-VLAN HW offload.
  4. Between WAN and LAN.

This is a great summary – perfectly clear!

You can always have a look at block diagram of a particular device:

Only ports, connected to “Switch”, are handled by switch chip and don’t directly “bother” CPU. In case of hAP ax3 that includes both ether1 and ether2-4 (they are actually all connected to same switch chip independently, block diagram slightly simplifies the view to emphasize the higher speed of ether1). So only traffic, passing between two ports connected to same switch (yes, there are MT devices with multiple switch chips), will be entirely handled by switch chip (if ROS does properly support HW offload which in case of hAP ax3 is not true).

As you can see, WLAN hardware is connected to CPU (each radio separately), which means that any traffic to/from any of radios will have to be handled by CPU … at least partially. E.g. if there’s traffic between two wireless devices, each station of separate radio (e.g. same SSID but different frequency band), then none of that traffic will ever touch switch chip, it’ll be entirely handled by CPU. There will be different software elements involved: wifi driver and (software implementation of) bridge. And in this case that’s true even for devices where switch chip support is more complete (e.g. hAP ac2).