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