Ok I think I see the issue.
I think for "download" direction you probably want a routing based solution. Put a Veth with one side connected to br-lan and route all incoming traffic from the WAN or WG interfaces to that. put cake on that.
2 Likes
So is the dual IFB not possible? I think I can see how the veth would work. I know how to do that for download. So then I just do the IFB for upload only. But before I do would be nice to know I can't just use two IFB's. I would prefer another IFB because I don't have to tinker with routing then.
Yeah, the problem is you want the IFB to be handling unencrypted an un-natted packets, which means that you have to handle them well after the ingress from the WAN/WG so the only way to handle them at that stage of the game is to get them routed to you...
1 Like
no for the download direction you don't need IFB1 at all and you just put Cake directly on the veth0.
1 Like
isn't it ingress on veth0, and so IFB is needed?
No, you put it on the egress of veth0, when it's routed, it will go through the egress, be sent to the br-lan and then distributed along the bridge.
1 Like
OK many thanks! working on this now..
@dlakelan does this look about right:
START=50
start() {
tc qdisc add dev veth0 root cake bandwidth 30Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 60
ip link add name ifb type ifb
tc qdisc add dev ifb root cake bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
tc qdisc add dev br-lan handle ffff: ingress
ip link set ifb up
tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass
tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb
}
stop() {
tc qdisc del dev br-lan ingress
tc qdisc del dev veth0 root
tc qdisc del dev ifb root
ip link set ifb down
ip link del ifb
}
does this catch traffic going from LAN to LAN, like a wired device talking to a wireless device?
that catches all traffic on br-lan that is NOT local, because:
First, this:
tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass
passes on a packet if it is destined for 192.168.1.0/24.
And this:
tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb
only copies packets not caught by priority 1 above.
So this only copies across the wan/vpn ingress traffic on br-lan to ifb..
Do you need cake on br-lan if it’s already catching download traffic on veth0?
In the upload direction you can just use cake on the wan interface for egress since Wireguard will make unique flow hashes available for flow fairness on wan egress.
2 Likes
Good point. You are right. Avoid IFB if not needed, right? I guess it's excess computation for little benefit...
.. oh and this means I don't even need script.
@dave14305 so like this (with veth-lan member of br-lan, and veth-wan the wan-facing veth into which download traffic is routed)?
root@OpenWrt:/etc/init.d# tc qdisc ls
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
qdisc noqueue 0: dev lan1 root refcnt 2
qdisc noqueue 0: dev lan2 root refcnt 2
qdisc noqueue 0: dev lan3 root refcnt 2
qdisc noqueue 0: dev lan4 root refcnt 2
qdisc cake 8039: dev wan root refcnt 2 bandwidth 30Mbit besteffort flows nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc noqueue 0: dev wlan1-1 root refcnt 2
qdisc noqueue 0: dev wlan0 root refcnt 2
qdisc noqueue 0: dev vpn root refcnt 2
qdisc cake 803c: dev veth-wan root refcnt 2 bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
qdisc noqueue 0: dev veth-lan root refcnt 2
I’m out of my league with veth. But simpler is better.
better terminology would be veth-br and veth-lan... both of them are facing the LAN but the veth-br is inside the bridge, whereas the veth-lan is external to the bridge and sends towards the bridge.
1 Like
Dear @moeller0, @dlakelan, @vgaetera, @dave14305
Thank you all for your patience with me and all the helpful insight.
It seems I have made a mountain out of a molehill, but I have enjoyed the ride.
For anybody wanting to set up SQM in the context of WireGuard + PBR, one easy solution is as follows:
For upload:
- apply cake on wan using 'flows nonat'
(as identified in this thread, WireGuard preserves flow hashes available for flow fairness on wan egress - so it really is this simple)
For download:
- set up veth-br, with peer veth-lan and add veth-br to br-lan
- route inbound traffic from vpn / wan to veth-lan
- apply cake on veth-lan
(this presents an interface that receives only vpn/wan traffic, and so avoids shaping lan<>router traffic)
5 Likes
But does it work the way you expect it? 
I am still to apply @moeller0's test, but from my basic testing so far seems to be working. So long as zoom and teams calls go uninterrupted despite Netflix and windows and Android/iPhone software updates then I'm happy.
I think a way to implement this on Asus Wrt Merlin would be to add veth-br to br0, reroute wan and VPN download to veth-lan and then create IFB on br-lan with the tc filter rules I gave above to filter out router-lan traffic. Something like:
ip link add name ifb type ifb
tc qdisc add dev ifb root cake bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
tc qdisc add dev br-lan handle ffff: ingress
ip link set ifb up
tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass
tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb
The QoS override script would facilitate that. But the rerouting would presumably need attention with respect to VPN Director.
Rerouting on OpenWrt is easy once you ditch the main straight jacket VPN PBR implementation and use netifd PBR with simple rules in LuCi (thanks for this insight @vgaetera and for your LuCi work to make this possible).
Merlin would take some convincing even though this would make CAKE work for all cases (no VPN, VPN, VPN with PBR, multiple VPNs etc.).
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.