On 03/12/12 03:47 AM, Andy Furniss wrote:
I don't think putting flow on the real if will work with mirred - it
would need to be on ifb and attached to the sfq(s).
I don't think (but am not sure) that nfct-dst will work on ingress as
the packet hasn't hit netfilter yet. If your openwrt is just routing and
doesn't have significant traffic to/from it apart from internet then you
could redirect from egress on the lan facing if(s) rather than ingress.
Okay, thanks for this insight. I haven't managed to activate cls_flow
yet, in even the most basic configuration, without stopping network
traffic altogether.
The basic configuration I tried is sfq root qdisc on eth0.2 (WAN
interface) on egress, no other qdiscs, and "dst" hash key, just like
this example [1]. Without an additional rate limiting qdisc, sfq should
do nothing (forward packets as fast as they arrive)
I disabled all of my traffic shaping script and rebooted, so no other
qdiscs or filters are configured. I confirmed that I can send and
receive traffic, and then ran:
insmod sch_sfq
tc qdisc add dev eth0.2 root handle 1 sfq
insmod cls_flow
tc filter add dev eth0.2 protocol ip pref 1 parent 1: handle 1 flow
hash keys dst divisor 1024
Almost immediately my internet traffic stops. When I remove cls_flow, it
starts again:
tc filter del dev eth0.2 protocol ip pref 1 parent 1:
Is there a mistake in this basic configuration? How can I investigate
why my internet traffic stops when I activate cls_flow? Would any other
details be helpful?
I think I need to fix this basic configuration before adding additional
qdiscs, or adding nfct-src hash key?
[1] http://thread.gmane.org/gmane.linux.network/84925/focus=85249
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
