good morning, I am trying unsuccessfully to limit the bandwidth of an ethernet port through a simple queue, the problem that that port is part of the briged.
Ether 1: wan
Ether 2,3,4,5: Briged 1.
Try to limit the bandwidth of port Ether 2 using a simple queue in target = Ether2. but it surely doesn’t work because it is part of the briged.
Is there a way to limit the bandwidth of an ethernet port that is part of a briged?
Thank you for your time,
greetings from Bolivia.
To make the queues handle L2 forwarding on a bridge, you must set use-ip-firewall to yes in /interface bridge settings. And I’m not sure whether /queue simple and target=ether2 will be sufficient, you may have to use queue tree and assign packet-mark. I don’t have any practical experience with this.
HW offload has to be disabled for that particular interface as well …
I had already marked ipsetthin, but the single queue on a port belonging to a briged does not work yet.
it does not work by deactivating the Hardware Offload option.
apparently it is not possible to limit the bandwidth on an ether port that belongs to a briged.
I don’t see why it should not be, but as you haven’t shown the complete setup, no one can tell what the real configuration mistake is.
Thanks for replying, I add the exported configuration:
/interface bridge
add name=bridge1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool3 ranges=192.168.2.2-192.168.2.254
/ip dhcp-server
add address-pool=dhcp_pool3 disabled=no interface=bridge1 name=dhcp
/queue simple
add max-limit=0/1M name=queue1 target=ether2
/interface bridge port
add bridge=bridge1 hw=no interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-pppoe=yes
use-ip-firewall-for-vlan=yes
/ip address
add address=192.168.1.80/24 interface=ether1 network=192.168.1.0
add address=192.168.2.1/24 interface=ether2 network=192.168.2.0
add address=192.168.2.2/24 interface=ether3 network=192.168.2.0
add address=192.168.2.3/24 interface=ether4 network=192.168.2.0
add address=192.168.2.4/24 interface=ether5 network=192.168.2.0
/ip dhcp-server network
add address=192.168.2.0/24 gateway=192.168.2.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 gateway=192.168.1.1
/system clock
As I’ve suspected in advance, the interface name used as simple queue’s target can only be a name of an L3 interface (at least in 6.45.7 where I’ve just tested it). L2 interfaces (member ports of bridges) are “invisible” to the simple queue’s matcher, so if you set an L2 interface name as a target, the queue will never match any packet or frame because no packet or frame ever gets an L2 interface name as an in-interface or out-interface attribute.
So to make the simple queue “notice” the frame, you have to assign a packet-mark to it (using /interface bridge filter action=mark-packet new-packet-mark=xyz), and you have to add the value xyz also to the packet-marks list which is one of parameters of the queue. When specifying the limits in download/upload format, for L2 interfaces, download is the direction wire->silicon and upload is the direction silicon->wire. Setting IP address as simple queue’s target has some effect on the packet matching but not the expected one, so either investigate it in detail or avoid it.
I was unable to assign a packet-mark to locally originated packets in chain=output or chain=postrouting of /ip firewall mangle depending on out-bridge-port, but that may be because of my VLAN configuration on the bridge, and I could not test in chain=forward. Without this to work, you have to know the IP addresses of devices connected via the bridge port in order to set the correct new-packet-mark in /ip firewall mangle to packets routed into the subnet which lives on the bridge, which probably ruins your idea.