Re: Problem with cls_flow nfct-* keys

[Andy Furniss <adf.lists@gmail.com>]

Гаврилов Игорь wrote:
> Hi everyone! I've discovered some issues with cls_flow nfct-* keys. I have a router with NAT and clients behind it. All incoming traffic from WAN interface is redirecting to ifb0 device. With HTB qdisc.
> I Am install SFQ qdisc 99:0 with flow classifyer and nfct-dst key on HTB deafault leaf class (1:99) :
>
>      tc qdisc add dev eth0 ingress
>      tc filter add dev eth0 parent ffff: protocol all pref 100 u32 match u32 0 0 action mirred egress redirect dev ifb0
>
>      tc qdisc add dev ifb0 root handle 1: htb default 99 r2q 10
>      tc class add dev ifb0 parent 1: classid 1:1 htb rate 10Mbit
>
>      tc class add dev ifb0 parent 1:1 classid 1:99 htb rate 2mbit ceil 10Mbit burst 150k prio 7
>      tc qdisc add dev ifb0 parent 1:99 handle 99: sfq limit 10240
>      tc filter add dev ifb0 parent 99: protocol all handle 1 flow map key nfct-dst and 0xff divisor 1024
>
> I am trying to achieve equal bandwidth sharing between internal IPs, so that single IP could not get all free bandwidth with Torrent. But it doesn't work. After investigation I've discovered, that all incoming traffic,
> that hit default HTB class (1:99), goes to SFQ class 99:1f, which equals to WAN IP of my router *.*.*.30, so I see that nfct-dst key behaves like a simple dst. Is there any chance to fix it?

I am not sure if this should work or not.

If there is no/low incoming traffic to this box then you could shape on 
egress.

Generally I would avoid redirecting protocol all then restricting htb 
default - you may end up dropping arp.

--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html