OK, this is driving me nuts.
basically a dumb access point with bridging the lan and wan ports correct?
Setup:
Att router/modem (passthrough mode) ----> mt300n (for sqm only) ----> linksys3200acm (stock)
Everything works minus the GL but I'm trying to utilize the GL as a bufferbloat appliance. It's not working far. GL has 18.06.4 on it.
I did solve this, but unconventionally. For some reason it wasn't working. After many many many resets I decided to install the GL inet latest firmware. In their GUI is an option to join the wan port as a lan port. Then I proceeded to change the change lan to this
att router 192.168.0.x --->>> GL inet 192.168.0.75 --->>> Linksystock 192.168.1.1
disable firewall, dnsmasq, and ohdhcpd.
install sqm
set eth0.2(wan port) as upload
set eth0.1 (lan port) as download
This avoids the ifb as pointed out by @moeller0 using two physical interfaces
root@bumpinthewire /root [~>]# cat /etc/config/sqm
config queue 'eth1'
option enabled '1'
option interface 'eth0.1'
option verbosity '5'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option linklayer 'ethernet'
option overhead '26'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '0'
option linklayer_adaptation_mechanism 'cake'
option debug_logging '1'
option download '0'
option upload '50000'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option ingress_ecn 'NOECN'
option egress_ecn 'NOECN'
option qdisc_really_really_advanced '0'
config queue
option verbosity '5'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '0'
option enabled '1'
option interface 'eth0.2'
option debug_logging '1'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option linklayer 'ethernet'
option overhead '26'
option linklayer_advanced '1'
option linklayer_adaptation_mechanism 'cake'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option ingress_ecn 'NOECN'
option egress_ecn 'NOECN'
option qdisc_really_really_advanced '0'
option download '0'
option upload '10000'
root@bumpinthewire /root [~>]# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdb3:2c2b:1ded::/48'
config interface 'lan'
option type 'bridge'
option proto 'static'
option hostname 'bump-in-the-wire'
option netmask '255.255.255.0'
option ipaddr '192.168.0.100'
option gateway '192.168.0.254'
option dns '192.168.0.254'
option ifname 'eth0.1 eth0.2'
config interface 'wan'
option proto 'dhcp'
option hostname 'bump-in-the-wire'
option metric '10'
config device 'wan_dev'
option macaddr 'e4:95:6e:48:f5:cc'
config interface 'wan6'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0 6t'
does this seem sound to you the way interfaces are setup? It seems that both interfaces are using the "upload" space but on eth0.1 the ingress is actually controlled. I understand the direction is inverted, which has my head spinning. My confusion is setting up additional classes and dscp marks in the correct direction.
If you want to shape to 50000/10000 [download/upload] that looks about right.
Well, yes and no, upload really denotes interface egress, and in both cases you instantiate the shaper on the send side of an interface, but from the vintage point of the internet, eth0.1's send/egress direction points into your private network and hence is equivalent with the internet-download direction. Does this make sense?
I would be confused by "setting up additional classes and dscp marks" the firection is comparatively easy 
Usually DSCP marking doesn't matter about the direction.
Instead of "upload" think "sending out of the port" and instead of download think "receiving into the port" and you'll be all set.
there is no ingress queue for an interface... SQM manufactures one by redirecting packets that are received on an ethernet port to be sent out of an "intermediate functional block" (IFB) interface which is kind of like a one-ended virtual interface... sometimes it's useful to have a two-ended virtual interface, and that's called a veth, which is sometimes used in some of the advanced QoS stuff we've seen discussed here as well.
I'm not at my home atm but I tried setting up a 3 class sqm script e.g. prio, normal,bulk. It showed no packets flowing through iand not indicating activity in the different classes despite the connection working. The goal is to keep the bump in the wire with seperate interfaces and have a 3 tier structure for each. I'm referring to each as ingress and egress to keep my sanity! lol
eth0.1 ( controls ingress bandwidth w/ tins)
prio
normal
bulk
eth0.2 (controls egress bandwith w/ tins)
prio
normal
bulk
P.S. I do have it working with only a single branch class for each direction. I do have dscp marks set on the main router running openwrt again now.
This is an interesting project to say the least. I already have friends begging me to create more of these for them because of the impact it has. Instantly using a basic script for hfsc/fq_codel I have recieved comments saying how clear I sounded online as opposed to before with the same sqm script running locally on the 3200acm. Offloads, pause frames, and interrupt coalescing disabled of course.
This is surprising to me. Were you using the same two interface strategy? the 3200acm has a LOT of CPU power, and should be able to handle 300Mbps or more so I don't think it's a CPU offloading issue. Perhaps a driver issue...
On the ACM were you running the wifi? Did you use a veth to provide a single input into the LAN bridge?
in any case, yes the strategy here is well founded.
I was using the typical ifb on the 3200ACm previously, which i'm trying to avoid using the ifb at all cost without heart surgery. This diy bitw is new to me, as I've never cared to actually inspect the internal workings before this. This project is more about promoting sqm and inserting it between an existing installation to not disrupt anything physically. More folks these days realize it's better to insert your own router vs an isp provided unit. This bitw is the perfect compliment to that for controlling bufferbloat with isp support imho. Can I expect this to work with multi tins or is it just limited to 1?
Well, the last numbers I remember is that both ifb or the veth approach result in ~5% less shaper throughput (in bidirectional RRI+UL stress testing), so yes these are not for free, but the cost really is no show-stopper either (if 5% makes a difference than in all honesty even without the ifb one is already on thin ice). That said, in a situation like yours with a dedicated ethernet interface in each direction neither ifb nor veth are necessary so avoiding them is a good idea
So in all honesty, I would go for layer_cake.qos (which defaults to 3 priority tiers) and configure fo per-internal-IP-fairness. Here are the default diffserv3's dscp to priority tin mapping:
/* Simplified Diffserv structure with 3 tins.
* Low Priority (CS1)
* Best Effort
* Latency Sensitive (TOS4, VA, EF, CS6, CS7)
*/
Then all you need to do is configure your filters to make sure the desired DSCPs are set for the correct traffic and you should be off to the races.
This depends, if you do double NAT and all your hosts masquerade behind the Linksystock 192.168.1.1 then the bitw might have issues with recognizing internal IP addresses properly, but layer_cake will still evaluate and prioritize based on dscps.
Yes it is double nat’d. Still the direction should be dual-dsthost for both? Meaning on the bitw upload boxes for advanced options.
Hmm.. depends on what you want. If you want to spread the bandwidth across all your internal LAN clients... then you can't be outside the NAT, because the bump in the wire will just see a single IPv4 towards the LAN side... the router itself (because NAT). Of course it'll work fine for ipv6!
If you do dual-dsthost on the egress towards the WAN... then you'll be sharing bandwidth equally across all the internet servers you are uploading to... that's a weird config.
I'd say for your config you don't really want per-ip fairness at all... Just let the dscp priority take care of it.
Also, you could make the bump just do bridging. I'd suggest to get rid of iptables entirely and move to nftables, and use an ingress table on each ethernet to tag DSCP.
Cake by default will instantiate triple-isolate, but dual seems to work much better. Setting the options to flows would disable ip fairness if I remember correctly.
Yes, but as @dlakelan said, with the bitw upstream of your OpenWrt router's NAT it will not see your internal packets internal IP addresses (not being the device doing the NAT it can not simply refer to its own conntrack tables to figure out the internal addresses, all it sees is the secondary router's external 192.168.0.0/24 address (unless it is a /16 but then the Linksystock should not do NAT)).
So outside of your internal network per-flow seems to be the best you can do...
as ipv6 becomes more common this may change though.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.