Re: [Cake] cake separate qos for lan

[Dave Taht <dave.taht@gmail.com>]

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.taht@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.