[Top] [All Lists]

Re: IMQ again WAS(Re: iptables breakage WAS(Re: dummy as IMQ replacement

To: hadi@xxxxxxxxxx
Subject: Re: IMQ again WAS(Re: iptables breakage WAS(Re: dummy as IMQ replacement
From: Andy Furniss <andy.furniss@xxxxxxxxxxxxx>
Date: Mon, 28 Mar 2005 14:55:16 +0100
Cc: Harald Welte <laforge@xxxxxxxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, Remus <rmocius@xxxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>, Nguyen Dinh Nam <nguyendinhnam@xxxxxxxxx>, Andre Tomt <andre@xxxxxxxx>,, Damion de Soto <damion@xxxxxxxxxxxx>
In-reply-to: <1112017546.1089.1048.camel@xxxxxxxxxxxxxxxx>
References: <1107123123.8021.80.camel@xxxxxxxxxxxxxxxx> <423F71C2.8040802@xxxxxxxxxxxxx> <1111462263.1109.6.camel@xxxxxxxxxxxxxxxx> <42408998.5000202@xxxxxxxxxxxxx> <1111550254.1089.21.camel@xxxxxxxxxxxxxxxx> <4241C478.5030309@xxxxxxxxxxxxx> <1111607112.1072.48.camel@xxxxxxxxxxxxxxxx> <4241D764.2030306@xxxxxxxxxxxxx> <1111612042.1072.53.camel@xxxxxxxxxxxxxxxx> <4241F1D2.9050202@xxxxxxxxxxxxx> <4241F7F0.2010403@xxxxxxxxxxxxx> <1111625608.1037.16.camel@xxxxxxxxxxxxxxxx> <424212F7.10106@xxxxxxxxxxxxx> <1111663947.1037.24.camel@xxxxxxxxxxxxxxxx> <1111665450.1037.27.camel@xxxxxxxxxxxxxxxx> <4242DFB5.9040802@xxxxxxxxxxxxx> <1111749220.1092.457.camel@xxxxxxxxxxxxxxxx> <42446DB2.9070809@xxxxxxxxxxxxx> <1111781443.1092.631.camel@xxxxxxxxxxxxxxxx> <4244802C.7020202@xxxxxxxxxxxxx> <1111788760.1090.712.camel@xxxxxxxxxxxxxxxx> <42470AF9.8050402@xxxxxxxxxxxxx> <424808F7.50101@xxxxxxxxxxxxx> <1112017546.1089.1048.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217
jamal wrote:
On Mon, 2005-03-28 at 08:39, Andy Furniss wrote:

Hmm - I just tried to recreate another test I did - which was using IMQ to shape for a single duplex link. I was going to redo it with dummy, but don't seem to be able to put an egress filter on eth0 - eg. Your example from the first post in this thread -

What you can do with dummy currently with actions

Lets say you are policing packets from alias
you dont want those to exceed 100kbps going out.

tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
match ip src flowid 1:2 \
action police rate 100kbit burst 90k drop

Gives me -

RTNETLINK answers: Invalid argument
We have an error talking to the kernel

Dont see why this shouldnt work. You are saying it works with
non-aliased interface addreses?

No it doesn't work at all.

I noticed default qdisc has handle 0:

#tc -s qdisc ls dev eth0
qdisc pfifo_fast 0: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 13024 bytes 95 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

but using parent 0: instead of 1: still fails.


<Prev in Thread] Current Thread [Next in Thread>