Jack Bates wrote:
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
Hmm, that's strange and I can't recreate it with current kernel/iproute2.
Maybe you have some unlucky version - one thing you could try, as you
are testing on root is use protocol all instead of protocol ip.
It's been years since I tested a vlan (your eth0.2 is a vlan isn't it?)
back then using vconfig.
To digress slightly from your issue to what I've just seen testing.
To test this I set up a vlan using just ip - it seems to work and your
example passes traffic, but strangely I can't get a protocol 802.1q
filter to see anything on the real interface.
On one box tcpdump -e just shows ip on the other with older tcpdump it
will show 802.1q passing but only on egress - yet a tc filter on the
real if still won't see 802.1q.
So it's possible that my vlan test wasn't so good at trying to recreate
your issue.
Anyone know what is expected behavior now with vlans?
All offloads were turned off with ethtool.
--
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
