On 27/11/12 01:51 PM, Andy Furniss wrote:
Jack Bates wrote:
How can I limit the *sum* of upstream plus downstream traffic on my WAN
interface (eth0.2) to < 1.5mbit? (in order to "own" my queue)
Unless you have a half duplex wan and I don't understand why you would
need to limit the sum of up and down.
Thanks Andy, our subscription is for 1.5mbit, and our traffic graphs
show that the sum of our upstream and downstream is never more than
1.5mbit. When the connection is saturated and one goes up, the other
goes down.
If you really need to do it, then it should be possible using ifb.
I tried to redirect both upstream and downstream traffic to dev ifb0
with the following two commands:
> tc filter add dev eth0.2 parent ffff: u32 match u32 0 0 action mirred
egress redirect dev ifb0
> tc filter add dev eth0.2 root u32 match u32 0 0 action mirred egress
redirect dev ifb0
But whichever order I run them in, the first filter has statistics while
the second filter has zeros:
root@OpenWrt:~# tc -s filter show dev eth0.2 root
filter parent ffff: protocol all pref 49151 u32
filter parent ffff: protocol all pref 49151 u32 fh 801: ht divisor 1
filter parent ffff: protocol all pref 49151 u32 fh 801::800 order 2048 key ht 801 bkt 0 terminal flowid ??? (rule hit 5702298 success 5702298)
match 00000000/00000000 at 0 (success 5702298 )
action order 1: mirred (Egress Redirect to device ifb0) stolen
index 2 ref 1 bind 1 installed 56076 sec used 0 sec
Action statistics:
Sent 2999742176 bytes 5702298 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
filter protocol all pref 49152 u32
filter protocol all pref 49152 u32 fh 800: ht divisor 1
filter protocol all pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? (rule hit 0 success 0)
match 00000000/00000000 at 0 (success 0 )
action order 33: mirred (Egress Redirect to device ifb0) stolen
index 1 ref 1 bind 1 installed 56076 sec used 56076 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
root@OpenWrt:~#
(If I run the two commands in the reverse order, then the "root" filter
has statistics while the "parent ffff:" filter has zeros)
Can you spot what I'm doing wrong? or suggest how to debug this? Can I
provide any more details that would help?
Here is the complete script that I tried:
> ifconfig ifb0 up
>
> insmod sch_ingress
> tc qdisc add dev eth0.2 ingress
>
> insmod cls_u32
> insmod act_mirred
> tc filter add dev eth0.2 root u32 match u32 0 0 action mirred egress
redirect dev ifb0
> tc filter add dev eth0.2 parent ffff: u32 match u32 0 0 action mirred
egress redirect dev ifb0
>
> insmod sch_tbf
> tc qdisc add dev ifb0 root handle 1 tbf rate 1mbit burst 5k latency 70ms
Also I notice that if I run the "root" command before adding the ingress
qdisc, I get "RTNETLINK answers: Invalid argument". I understand why I
might get an error if I try to redirect ingress traffic ("parent ffff:"
filter) before adding the ingress qdisc, but I'm confused why I get an
error trying to redirect egress traffic ("root" filter), and why adding
the ingress qdisc resolves it:
root@OpenWrt:~# tc filter add dev eth0.2 root u32 match u32 0 0 action mirred egress redirect dev ifb0
Action 4 device ifb0 ifindex 7
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
root@OpenWrt:~# tc qdisc add dev eth0.2 ingress
root@OpenWrt:~# tc filter add dev eth0.2 root u32 match u32 0 0 action mirred egress redirect dev ifb0
Action 4 device ifb0 ifindex 7
root@OpenWrt:~#
--
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
