I have a simple queue that is supposed to limit bandwidth on the wireless interfaces.
0 name="queue-gasten" target=wifi3-gasten,wifi4-gasten parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=3/3
burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
This used to work on v6, but after upgrading to v7 it no longer works.
Fasttrack with Simple Queue?
“max-limit=3/3” - you meant “3M/3M”? 
Fasttrack has been disabled. I created the queue long ago on v6. And yes, 3M/3M. I changed it to see if there had been a change in units, but forgot to revert it before exporting the queue
I noticed these settings no longer worked when I added a new wireless router with v7. I created the same queue, but it did not work. So I checked with the v6 device and everything was the same, except that on v6 it worked and on v7 it did not. I have now upgrade the v6 device to v7 and that too has stopped working.
Just tried creating a new queue on 7.14.2 and it works as expected without fasttrack
/queue simple add max-limit=3M/3M name=queue1 target=bridge
So, use bridge
The queue is meant to limit the guest wifi only, so using it on the bridge kind of defeats the purpose.
Also, it does not work for me.
With regards to fasttracking, the firewall is not being used. All ethernet and wifi interfaces are part of the bridge, so no forwarding of any kind.
I have tried this on 6 devices. Three new ones, hAP ax2 v7.14.2, and 3 older ones, v6. All v6 devices work just fine, until I upgrade them to v7. Then the queue stops limiting bandwidth. Once downgraded to v6, they queue works again. No changes to the configuration, just upgrading to v7 or downgrading to v6.
Use guest bridge.
Yes. But simple queue only works without fasttrack.
Or you can disable IP - Settings - Allow Fast Path
There is no “guest bridge” or whatever you may mean by that.
There is a central firewall/DHCP-server. So the APs are in bridge mode. Just as they have been for years with the v6 APs. The v6 APs limit bandwith for the WIFI interfaces only. This works fine. Only the new v7 APs do not work the same. Once I upgraded the v6 devices to v7, they stopped working too. Downgrading to v6 makes them work again.
Clearly, something is different between v6 and v7.
Clearly, that is not true. I have had the v6 APs working just fine in full bridge mode. No forwarding, so no fasttracking. It is v7 that has changed something.
Something 
We are talking about a major upgrade of the OS.
You could consider using a V6 config (if that is available?), after performing a netinstall to V7.14.2 (or other) doing a manual config by use of the V6 config file.
Duh, 
I am not quite sure what you mean by that. I was using a configured and working as expected v6 device. That stopped working as expected after the upgrade and no change to the configuration. It started working again after the downgrade.
I have also tried the exact same configuration on v7 devices. Starting from scratch and using the same configuration as with the v6 device.
Conclusion was, the configuration works as expected with v6, but not with v7. So, either v7 broke something, or v6 was broken and v7 fixed it.
Meanwhile, I have been going through the entire manual looking for what might be the case. Apparently, it was v6 that was "broken". More on that to follow.
Nice finding! 
Looking forward to your update!
As it turned out, simple queues on v6 work slightly differently than on v7. Maybe because of a design change, maybe because v6 did not work as intended and v7 fixed that. It took a “bit” of manual diving to find the solution.
The first clue is here: https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching. Under bridge settings it says:
use-ip-firewall (yes | no; Default: no) Force bridged traffic to also be processed by prerouting, forward, and postrouting sections of IP routing (see more details on Packet Flow article). This does not apply to routed traffic. This property is required in case you want to assign Simple Queues or global Queue Tree to traffic in a bridge. Property use-ip-firewall-for-vlan is required in case bridge vlan-filtering is used.
Below the list of settings is a note that clarifies a bit more.
In case you want to assign Simple Queues or global Queue Trees to traffic that is being forwarded by a bridge, then you need to enable the use-ip-firewall property. Without using this property the bridge traffic will never reach the postrouting chain, Simple Queues and global Queue Trees are working in the postrouting chain. To assign Simple Queues or global Queue Trees for VLAN or PPPoE traffic in a bridge you should enable appropriate properties as well.
On v6, this setting is also disabled by default, but for some reason traffic is being passed to the simple queue anyway. This explains why it stops working after the upgrade. After enabling the setting, the queue is applied as expected.
What is a bit worrying is that I also raised a ticket with Mikrotik support and the response I have had sofar does not point to this explanation and gives a completely different solution that does not work and is simply contradicting the manual and real life experience.
It was said that simple queue is designed to work with addresses, not interfaces. Which is clearly wrong, because webfig happily accepts interfaces and does not flag the queue as invalid. Also, I am using it with interfaces right now and it works just fine now that I have enabled use-ip-firewall.
Hi,
I see the same behavior as Erik.
On CCR1016 ROS v6.49.15 simple queue working OK,
but the same rules on CCR2004 (tested w ROS v7.12.2,7.14.2 and 7.15.2) not working.
Enabling/disabling bridge general setting property “Allow fast path”,“Use IP firewall” and “Use IP firewall for VLAN” do not have any impact.
Tested 2 rules(one with bridge interface name a second with IP range):
/queue simple print
name="LAN" target=bridge-LAN parent=none packet-marks="" priority=2/2
queue=default-small/default-small limit-at=0/0 max-limit=50M/50M
burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s
bucket-size=0.1/0.1
name="test" target=192.168.1.0/24 parent=none packet-marks=""
priority=8/8 queue=default-small/default-small limit-at=0/0
max-limit=60M/60M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s
bucket-size=0.1/0.1
I will make some investigation on Monday and wrote more …
Su_mi
Solved.
After some investigation (CCR2004 ROS v7.15.2) I found,that the only settings that have effect is disabling fasttrack forward rule in /ip firewall filter:
27 X ;;; Established a related forward fasttrack
chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related
After disabling fasttrack rule, Simple queues working OK:
/queue simple print
name="test" target=192.168.1.0/25 dst=ether16-GW parent=none
packet-marks="" priority=8/8 queue=default-small/default-small
limit-at=0/0 max-limit=100M/100M burst-limit=0/0 burst-threshold=0/0
burst-time=0s/0s bucket-size=0.1/0.1
name="LAN" target=bridge-LAN dst=ether16-GW parent=none packet-marks=""
priority=2/2 queue=default-small/default-small limit-at=0/0
max-limit=100M/100M burst-limit=0/0 burst-threshold=0/0
burst-time=0s/0s bucket-size=0.1/0.1
Both of two rules make the same and working as expected - one with IP range and second with interface name.
(bridge-LAN have IP range 192.168.1.0/24,PC stations is in lower half of range)
General switch settings “Use IP firewall” does not have any impact:
/interface bridge settings print
use-ip-firewall: yes
use-ip-firewall-for-vlan: yes
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: no
bridge-fast-path-packets: 1054215
bridge-fast-path-bytes: 983202645
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0
/interface bridge settings print
use-ip-firewall: no
use-ip-firewall-for-vlan: yes
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: yes
bridge-fast-path-packets: 1894760
bridge-fast-path-bytes: 1769905335
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0
Shapping working as expected regardless of “Use IP firewall” property is enabled or disabled.
“Fast forward” property of bridge-LAN interface does not have any impact too.
su_mi