Hmm, OK. Do you know if it is possible to create IFB based on egress (not just ingress), and if so how to implement that? Then I can easily create two IFB's for br-lan....
Along the lines:
tc qdisc add dev br-lan handle ???: egress
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
I just lack the syntax / knowledge as to how to create such an IFB for flow in the opposite direction to the normal ingress case.
I don't understand the goal here, which packets are going to which IFB? You want all packets to go through ONE device if you want to limit TOTAL bandwidth.
@dlakelan - it's 30Mbit for upload and 30Mbit for download, i.e. one ifb for upload traffic @ 30Mbit/s and a separate ifb for download traffic @ 30Mbit/s. Is that possible and if so how, see below.
I can just shape on br-lan - that works except it includes LAN<>ROUTER and ROUTER<>LAN traffic. So I would like to take out 192.168.1.0/24 traffic from interface to apply CAKE on. Then I have solved the problem. But how do I do that? It seems that aside from rerouting traffic on router the best way is using 'tc filter' like:
tc qdisc add dev br-lan handle ffff: ingress
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
That beautifully takes out local traffic.
For br-lan that would only take care of the outgoing upload, but how would I then do the same for the download? I am thinking I could create another IFB to 'tc filter' on that, but I don't know how to do that...
Something like the below (I just can't figure out the syntax - can you help?):
tc qdisc add dev br-lan handle ???: egress
tc filter add dev br-lan parent ???: protocol ip prio 1 u32 match ip src 192.168.1.0/24 action pass
tc filter add dev br-lan parent ???: prio 2 matchall action mirred egress redirect dev ifb2
A br-lan based solution would have the benefit of working in all cases even without use of a VPN at all. And VPN with or without PBR would not break it.
And all the flows are nice and unencrypted.
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