For some reason I can’t get the queues to work.
I have set up a simple lab system - RB750G, firmware 6.45.3
ether 1, 2 and 3 are bridged as WAN,
ether 4 and 5 bridged as LAN (Not used).
ether1 connects to internet, ether 2 and 3 to two Dell PowerEdge systems.
allow-fast-path is set to no.
No firewall rules set
I’ve created a very simple queue, but no traffic flows though it. I’ve tried various targets (WAN, ether2, IP address of PowerEdge). Nothing seems to work.
What am i doing wrong?
queue simple print
Flags: X - disabled, I - invalid, D - dynamic
0 name=“global” target=ether2 parent=none packet-marks=“” priority=2/2 queue=default-small/default-small limit-at=10M/10M max-limit=10M/10M
burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
if you are sure fasttrack is not activated in forward chain, then the next comes to mind is the target, it shouldn’t be set to 0.0.0.0 in simple queue, these two are the most common why it doesn’t work
I have disabled disabled fast-path in ip/settings (see below)
I think the issue may be in the fact that the IP on the bridge is set to the same range as the IP addresses of the two systems.
If I move them to the LAN sections (with other IP addresses of course), the traffic passes through the queue.
(I am not using 0.0.0.0/0 as target, but did try the ports, as well as the IP addresses of the PowerEdge systems.
Is it possible to use queues for bridged traffic?
ip settings print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-neighbor-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
route-cache: yes
allow-fast-path: no
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: no
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0
I will do further testing, but I believe the solution is to use-ip-firewall=yes in the bridge configuration.
The setting of allow-fast-path does not seem to make a difference.
Thanks for your help!
interface bridge settings print
use-ip-firewall: yes
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: no
bridge-fast-path-packets: 0
bridge-fast-path-bytes: 0
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0
For queues to work, traffic has to be handled by ROS in software. Which means it should not be HW offloaded. Every ROS device having a switch chip (RB750G has one) can HW offload one bridge with simple configuration (simply forwarding frames, no VLAN stuff). You have two bridges so ROS automaticaly selects a bridge to offload, but likely with all ports on LAN bridge disabled it’s WAN bridge that is HW offloaded.
Now there a few ways to force traffic through software. One is, as you discovered yourself, to enable use-ip-firewall=yes on bridge, but that might mess with traffic (firewall rules don’t behave exactly the same way for bridged traffic as they are for routed traffic and it’s single setting for all bridges). Better way for forcing traffic through software is to explicitly disable HW acceleration for port where you want to shape traffic. If you want to shape traffic on WAN link (but you’re OK with faster troughput between the rest of bridged ports), then run
/interface bridge port
set [ find interface=ether1 ] hw=no
Hello mkx.
That would be a very nice and direct solution!
I tried it, but it does not yet work for me. I started with disabling HW offload on ether2 and 3. That did not work.
I then disabled hw offload on all three ports of the bridge (see below). That does not work either,
I also tried to disable HW offload on all ports.
So far the only way to get it to work is to use the use-ip-firewall=yes on the bridge.
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
0 ether2 WAN no 1 0x80 10 10 none
1 ether3 WAN no 1 0x80 10 10 none
2 I ether4 LAN yes 1 0x80 10 10 none
3 I ether5 LAN yes 1 0x80 10 10 none
4 ether1 WAN no 1 0x80 10 10 none
Could be that indeed IP firewall has to be involved for queuing to work. It is not very common to have traffic shaping enabled between bridged/switched ports.