Code:
/interface bridge add name=bridge_lan/interface ethernet set [ find default-name=ether1 ] name=ether1_fibre/interface ethernet set [ find default-name=ether5 ] name=ether5_switch/interface eoip add !keepalive mac-address=02:1C:69:12:FF:2E mtu=1500 name=eoip-spareroom remote-address=192.168.110.2 tunnel-id=110/ip pool add name=dhcp ranges=192.168.11.200-192.168.11.254/ip dhcp-server add address-pool=dhcp interface=bridge_lan name=dhcp1/interface pppoe-client add add-default-route=yes allow=pap default-route-distance=10 disabled=no interface=ether1_fibre keepalive-timeout=15 name=pppoe-out1 profile=pppoe1/interface bridge port add bridge=bridge_lan interface=ether5_switch/interface bridge port add bridge=bridge_lan interface=eoip-spareroom/interface bridge settings set allow-fast-path=no use-ip-firewall=no/interface list add name=wan_qos/interface list member add interface=pppoe-out1 list=wan_qos/ip address add address=192.168.11.1/24 interface=bridge_lan network=192.168.11.0/ip address add address=192.168.110.1/24 comment="spare room eoip gateway" interface=bridge_lan network=192.168.110.0/ip firewall mangle add action=mark-packet chain=prerouting in-interface-list=wan_qos new-packet-mark=test passthrough=no/queue type add fq-codel-quantum=300 kind=fq-codel name=fq_codel/queue tree add bucket-size=0 max-limit=25M name=WAN_DOWN packet-mark=test parent=global queue=fq_codelI hope someone can help me figure out this gremlin (or confirm it as abnormal behaviour that should be reported as a bug?). I've posted a simplified version of config export to hopefully speed up analysis (I don't think anything omitted is important/needed to properly reproduce the issue described) but I will share full config if really needed
Setup looks as follows:
- Main router is an RB4011
- I have a unifi AP attached to ether5 of the main router
- In a spare room is another mikrotik (hAP ac lite) with nothing else configured except a station wireless link (IP=192.168.110.2) to the UAP, and an EOIP tunnel on its bridge, so that a desktop PC connected to the ethernet of the spare mikrotik will be able to have layer-2 access to the same bridge as the main router
- Spare room PC's IP (on remote end of the eoip tunnel) is 192.168.11.123.
Basically the problem I'm having is that when the desktop PC in the spare room downloads anything, it gets half the speed of the queue tree..
Let's say I am doing a download that saturates the queue: On the desktop at the endpoint of the eoip tunnel, I will only be getting around 11Mbps throughput while the queue tree will show near 25Mbps of avg throughput and "red status" throttling intensity.
The only way I was able to avoid this problem so far was to connect the spare room router directly to the RB4011's own wifi interface (where this wifi interface is not on the bridge) and set the parent of the queue tree to bridge instead of global. The problem with doing this is that any traffic taking place on the router itself (including wireguard tunnels) is then no longer part of the queue. So for that reason I need the queue tree to remain on global...
Something else interesting I've noticed is that If I add a filter/mangle rule to log packets forwarding to 192.168.11.123 (the spare room pc), there does not appear to be any duplication of packets/interfaces. It's just flowing via bridge as normal. If I action=fasttrack that rule, then I get full speed to the spare room pc (so it's not a wifi throughput issue). This problem is only happening to hosts at the remote side of the EOIP. Other clients connected to ether5 (including wifi clients to the unifi AP) are shaped normally (around 20-23Mbps download speed).
I've never really seen this issue before. Not sure if it's something on the RB4011, a bug in RouterOS, or an issue with the configuration? The workaround of using the RB4011's unbridged wireless for the eoip transit, seems to prove that the queue is being applied to both the EOIP tunnel as well as its parent interface, even if the host's IP is only assigned over the EOIP tunnel. Surely that is not normal? The bridged EOIP interface should be treated like any other bridged interface and queue should only apply to remote host once...
The end objective is that clients at the remote end of the bridged EOIP tunnel shouldn't be double-QOS'ed.
Any hints/solutions would be greatly appreciated?!!
Statistics: Posted by fragtion — Wed Jan 03, 2024 12:16 pm