[Cake] cake separate qos for lan
allan316 at gmail.com
Thu Mar 31 07:49:38 EDT 2016
>I gave this a shot, it doesn't route the packets back trhough the
>perhaps policy routing?
tried it with policy routing too, packets get dropped when i point them to
the ifb interfaces fast/slow. tried both dummy and ifb.
ip route add $custip dev fast table 10
ip route add $custip dev slow table 11
ip rule add from $cacheip to $custip lookup 10 priority 10
ip rule add from all to $custip lookup 11 priority 11
im not sure if we can route it to ifb this way,( maybe only works with tc
redirection?) as i feel that i have just set up a routing loop.
i did not have time to recompile the kernel for imq, as jonathan mentioned
but will try that too,
did not try the ifb method mentioned by jonathan yet.
On Wed, Mar 30, 2016 at 5:46 AM, Dave Taht <dave.taht at gmail.com> wrote:
> 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 220.127.116.11,1
> > insert customers 2001:db1::/64,1
> > insert customers 18.104.22.168,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 22.214.171.124/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 126.96.36.199/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 at lists.bufferbloat.net
Thanx and regd's.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cake