On Mon, Sep 10, 2018 at 12:29 PM Pete Heist <[email protected]> wrote: > > > On Sep 6, 2018, at 8:51 PM, Pete Heist <[email protected]> wrote: > > On Sep 6, 2018, at 8:04 PM, Toke Høiland-Jørgensen <[email protected]> wrote: > > Pete Heist <[email protected]> writes: > > But now, my neighbor will access the Internet through my CPE device, > but they must have a separate IP obtained through DHCP (i.e. a > separate MAC address as well), and I want to use cake to manage the > queue for both of us. I could do this with two routers and a > transparent bridge, but I want to see if I can make it work with as > few devices as possible, preferably just one EdgeRouter-X. I had two > failures thus far: > > > DHCP relay and normal routing? Or bridging with a kernel software bridge > rather than the hardware switch? > > > I bet a regular software bridge would work. I’ll try it. > > It looks like I’ll also need to do stateful firewalling for the neighbors. I > was able to get my transparent bridge to do this with > net.bridge.bridge-nf-call-iptables=1, I believe, so this should also > theoretically work fine, somehow… :) > > > For anyone who followed this, yes, the regular soft bridge (i.e. set > interfaces bridge br0) works fine on the ER-X, as I suspect it would on most > any Linux. A few notes about it: > > - Your qdisc must be added to the physical interface (e.g. eth4), not the > bridge interface > - Unlike the hardware bridge which has its own MAC, the soft bridge seems to > take the MAC of the lowest (or first listed?) interface port > - On ER-X, bridge-nf-call-iptables=1 is the default so nothing needs to be > changed there for firewalling > - When firewalling the bridged WAN interface, ‘in’ corresponds to bridged > traffic and ‘local’ to routed traffic, which is different from the semantics > for ordinary routed traffic > - I can do stateful firewalling for bridged hosts with “accept established > and related”, but have to explicitly allow DHCP (UDP source/dest port 67-68) > in the WAN interface’s ‘in’ rules for DHCP traffic to pass through the bridge > > Performance: > > Using Cake with this setup, the fun ends at around 110 Mbit with ksoftirqd > thrashing. Unsurprisingly, there’s probably some overhead here with the soft > bridge. For my purposes though (50 Mbit), it’s enough, barely…
Can I encourage you to give regular ole htb+fq_codel sqm a shot with a bigger burst and cburst size for htb? Fiddling with the htb quantum isn't helping much, but try this, from: https://github.com/tohojo/sqm-scripts/issues/71 (I am thinking burst and cburst should be about 1.1ms of buffering in size) root@apu2:/home/d/git/sqm-scripts/src# git diff . diff --git a/src/functions.sh b/src/functions.sh index 226a6c5..8ad4f38 100644 --- a/src/functions.sh +++ b/src/functions.sh @@ -364,7 +364,9 @@ htb_quantum_linear() { sqm_debug "HTB_QUANTUM (linear): ${HTB_QUANTUM}, BANDWIDTH: ${BANDWIDTH}" - echo $HTB_QUANTUM + echo $HTB_QUANTUM >> /tmp/taht.log + echo 32000 +#$HTB_QUANTUM } # Fixed step scaling @@ -438,7 +440,7 @@ get_htb_burst() { if [ -n "${HTB_MTU}" -a "${SHAPER_BURST}" -eq "1" ] ; then BURST=$( get_burst $HTB_MTU $BANDWIDTH ) if [ -n "$BURST" ]; then - echo burst $BURST cburst $BURST + echo burst 96000 cburst 96000 else sqm_debug "Default Burst, HTB will use MTU plus shipping and handling" fi > > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
