[Cake] cake separate qos for lan

Dave Taht dave.taht at gmail.com
Tue Mar 29 20:16:11 EDT 2016

I gave this a shot, it doesn't route the packets back trhough the
underlying interface...
perhaps policy routing?



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!

On Tue, Mar 29, 2016 at 4:31 PM, Dave Taht <dave.taht at 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
> insert customers 2001:db1::/64,1
> insert customers,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 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 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.

More information about the Cake mailing list