I gave this a shot, it doesn't route the packets back trhough the underlying interface... perhaps policy routing?
TC=/home/d/git/tc-adv/tc/tc IFACE=eno1 F=2601:640:4103:56c0:2ab4:103a:39c5:a43a S=2601:640:4103:56c0:120d:7fff:0:647 ip link add $IFACE name fast type dummy # maybe ifb? ip link add $IFACE name slow type dummy # maybe ifb? ip link set fast up ip link set slow up $TC qdisc add dev fast root cake bandwidth 20Mbit $TC qdisc add dev slow root cake bandwidth 5Mbit $TC qdisc add dev $IFACE root cake bandwidth 20Mbit ip route add $F dev fast metric 1 ip route add $S dev slow metric 1 Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Tue, Mar 29, 2016 at 4:31 PM, Dave Taht <dave.t...@gmail.com> wrote: > An overall ISP in tc need exposed by this discussion is some means of > mapping multiple ipv4 and ipv6 addresses and netmasks into something > that will return a (key,value) pair. This would work something like > ipset does, although what you would return is not "present or not" but > present and a value > > insert customers 1.1.1.1,1 > insert customers 2001:db1::/64,1 > insert customers 2.2.2.2,2 > insert customers 2001:db2::/64,1 > > then on the relevant path you'd set up the qdisc hierarchy and do a > lookup into that to get the right number to go to the right cake > instance. You'd also have to do a longest prefix match into the above, > so a 1x1 hash won't do. > > the massive tc filter option discussed already does not scale to a > random number of customers with randomly different numbers of ip > addresses, types, and netmasks. Code like this must exist in dedicated > devices already, CMTSes, BRASes, deep packet inspection devices, etc. > > Secondly, in the case of cake the hierarchy could just be a bunch of > somewhat unassociated queues, not htb or drr, letting cake do the > scheduling of deliveries. > > Regrettably I know of few ISPs that are actively using linux in any > way they have sources to. I suspect a few dslams are linux based, but > nobody's talking. > > ... > > Another way to maybe get there is to use the ip route functionality > instead and send stuff to virtual devices layered on top of the real > device. > > ip route add from :: to 1.1.1.0/24 dev dev1 > ip -6 route add from :: to 2001:db1::/64 dev dev1 > ip -6 route add from :: to 2001:db2::/64 dev dev2 > ip route add from :: to 2.2.2.0/24 dev dev2 > > Then the reverse would be out one of two devices, one device > configured for the "fast, local cache server", the other for the > regular internet. > > solution too long to fit in the margins of this email. _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake