I do use ifb, which does the same job as imq and it is in the mainline kernel.
On 04/02/17 05:51, Konstantin Shalygin wrote:
> On 02/04/2017 02:01 AM, John Sager wrote:
>
>> I've got 6 categories of traffic, which map onto 6 fwmarks which are used by
>> the HTB filters. I could easily use iptable
On 02/04/2017 02:01 AM, John Sager wrote:
I've got 6 categories of traffic, which map onto 6 fwmarks which are used by
the HTB filters. I could easily use iptables to map those onto dscp marks
for cake to use on egress, but I still need the fwmarks (transferred to
conntrack) to classify ingress
No problem. The distro I use for my firewall (LEAF-bering) doesn't support
cake yet, though I could build the module & cake-aware tc with its
toolchain, so I'll continue with HTB+fq_codel & keep an eye on this list.
John
On 03/02/17 19:30, Jonathan Morton wrote:
>
>> On 3 Feb, 2017, at 21:01, Jo
> On 3 Feb, 2017, at 21:01, John Sager wrote:
>
> As cake uses diffserv to classify, it would be good to carry dscp in the
> conntrack & transfer it to incoming packets with an 'action' on the ingress
> filter, but carrying dscp specifically in the conntrack record would be
> quite a significant
On 03/02/17 17:08, Dave Taht wrote:
> On Fri, Feb 3, 2017 at 8:42 AM, John Sager wrote:
>> I would support this. It would allow cake to behave pretty much as I have
>> HTB+fq_codel currently set up for both egress and ingress (via ifb0) on my
>> border router/firewall. I fwmark egress traffic ba
On Fri, Feb 3, 2017 at 8:42 AM, John Sager wrote:
> I would support this. It would allow cake to behave pretty much as I have
> HTB+fq_codel currently set up for both egress and ingress (via ifb0) on my
> border router/firewall. I fwmark egress traffic based on various criteria
> using ip[6]tables
I would support this. It would allow cake to behave pretty much as I have
HTB+fq_codel currently set up for both egress and ingress (via ifb0) on my
border router/firewall. I fwmark egress traffic based on various criteria
using ip[6]tables & transfer the marks to conntrack where they are recovered
> On 31 Jan, 2017, at 16:49, Felix Resch wrote:
>
> Since we now already do the conntrack-lookup for the nat keyword, would it be
> expensive to implement a kind of internal conntrack-mark-and-restore by
> cake-tin?
>
> E.g. when traffic leaves throu canke tin#x, the conntrack entry will get
