It might, but it would also add a bunch of cpu overhead compared to just shoving it in a separate namespace I believe.
i have another idea but not sure if it's right or will work properly, the idea is:
1.create a new bridge lets call it br-all.
2.add other br-vlan's to this br-all.
3. use ebtables to prevent each br-vlans to not talk to each other.
4.add veth1 to br-all.
5.add veth0 to a new routing table, then use sqm on veth0.
can you kindly post the commands that you have used to create the second name space?!
also I think this could work, but becomes much more of a security issue, and also will kinda break the structure of the OpenWrt firewall I think.
For most people, I think just create the bridge between the wan ethernet and veth0 and off you go, no namespace needed and no strange ebtables manipulation unless a lot of services like squid or something run on the router, in which case, just shove the prewan into a separate namespace and it works. It's not more than a few commands to do the namespace thing, like 5 or 6, to set up the namespace, to move the devices, and then create the bridge in the other netns and load the DSCP tagging rules.
so if someday i created a guest network, then is it enough to just bridge between the wan ethernet and veth0.
then establish a wan connection on veth1.
after this i have to use sqm on veth0 and veth1 ? is this correct!
do you bridge the second namespace to the original machine default space.
Yes, because all the traffic will go through veth0-veth1 and then be distributed out to your guests or LAN or whatever, so it will all get prioritized.
Of course you want to set your DSCP values in the firewall too! I think that requires you to have bridge netfilters enabled and a rule that allows forwarding packets from the prewan firewall zone to the prewan firewall zone. SO you'll want to put the br-prewan into its own prewan firewall zone and set your firewall to allow forwarding from prewan to prewan and prewan to wan. The prewan to prewan rule needs to be its own traffic rule because normally that doesn't happen so the firewall doesn't think about it.
In my config which requires the namespace, I put veth0 into the prewan namespace, and leave veth1 in the main namespace. Now veth1 appears to be my WAN.
but strange when i run:
ip netns add prewan
it will show this error:
Failed to create a new network namespace "prewan": Invalid argument
Hmm, I'm doing this stuff on a Debian server, I only tried the bridge without the netns on OpenWrt, perhaps there are kernel mods needed to be installed?
i have a lot of kmod's installed, so not sure what is needed for this to work!
ip netns help Usage: ip netns list ip netns add NAME ip netns set NAME NETNSID ip [-all] netns delete [NAME] ip netns identify [PID] ip netns pids NAME ip [-all] netns exec [NAME] cmd ... ip netns monitor ip netns list-id
i think the problem is laying here
At the moment we can't use network namespace!?!
BTW: you can see interested things if you run
Further testing shows that when I put iptables / ip6tables into my prewan netns and just use mangle table to adjust DSCP, things don't work at all, I get highly erratic speeds, with upload eventually dying out entirely due to massive numbers of TCP resets...
I am not sure what goes on there, it seems unclear, for the moment I get Fabulous results without the DSCP, and of course I am still reordering packets because I have a shaper on LAN, so for now I am not using iptables to dscp tag in the prewan namespace. So, you might ask, why use it at all? I definitely do get better results with the prewan shaper, so I think this is down to some quirks of my particular setup which is in fact very quirky.
I'll open a new thread on this once I've done debugging and can report a good working config.
Here is speedtest with prewan namespace but no iptables operating in the prewan namespace. It has a shaper on veth0 and veth1 and LAN
as you can see, pretty darn good! This definitely requires the full power of an x86 at these speeds.
Also, this is about the best I've ever gotten in my setup. Clearly the veth method is pretty good, even if I can't figure out how to do the bridge netfilter dscp tagging. The DSCP tagging does happen in routing in the main namespace, and a shaper on the LAN output then prioritizes things properly. I guess somehow maybe the pre-wan shaper does a better job of modeling the WAN connection than the LAN shaper does because my LAN is faster than my WAN.
anyway, I'll take it for the moment
@dlakelan will Macvlan help us in the multiple br-vlans without using namespace or in your case!
Don't think so. I've been working on nftables all day, changed my whole firewall, now going to look at nftables ingress filters.
BTW, if you try nftables, have a look at the new nft-qos package which promises per IP/subnet throttling via a luci interface, which might be a good starting point for a dscp remarker app, if instead of using the rate limiter one optionally rewrites the dscps. Note, I have not tested yet how this behaves in regards to latency under load/bufferbloat since I have not managed to get it installed yet (would need to compile firmware from source and am lacking diskspace to do so).
@dlakelan good luck with configuring nft.
but what is the real benefit of nft, simplicity,less rules?
but will this force you to use tc, in this case we can't use sqm diffserv classes?!
@moeller0 but how we would tag packets with nft qos?
is there any classes,prioritization?
this mean we will loss sqm bufferbloat, or we should make sqm work with nft instead of iptables?
for dscp will we use something like this?
ip forward ip dscp set 42
also is there any attempts to make openwrt firewall based on nft instead of iptables, or any new package
I run a Debian router with fireqos, converting to nftables made my config easier to understand and much simpler, I suspect faster too, fireqos had hundreds of rules in tens of chains, my nftables has around 20 lines of code
When I tried to use iptables to tag dscp in my prewan namespace my speed dropped from 750 megabits to about a megabit, and erratic. So this motivated me to look into it.
I run openwrt on my access points, who have a lighter duty.
Nftables let's you select classes by using the priority action, so it can be used instead of TC, which is a big benefit because TC is terrible to use. I think it means while tagging dscp also you can select classes.
Too funny, that's much smaller and will take less space from disk.
hhhaah,really strange.use nft to tag packets with dscp.
it will make things easier, i think this will allow sqm to run on nft instead of tc!.
tc is not well documented and hard to understand, still i can't understand what does priomap do or how to config it