Hi Andy,
please, have a look at my answers in the text below.
On Mon, 2006-06-26 at 13:33 +0100, Andy Furniss wrote:
Nikolay Kichukov wrote:
Hello everybody on the list,
I have the following situation where I want to police the speed of
incoming
packets from specific subnets to 1024kbps and then police all the rest to
256kbps, which is the speed my ISP grants for the rest of the internet.
If you are shaping ingress you will need to set a rate below the link
speed, or you won't do anything.
How about a rate that matches the link speed? Will 95% of the link be
alright for ingress?
So, eth1 is the one connected to the cable modem and then to the internet.
I do:
tc qdisc add dev eth1 ingress handle :
then:
tc filter add dev eth1 parent : protocol ip prio 1 u32 match ip src
xx.yy.zz.0/24 police rate 1024kbit burst 10kb drop flowid :
tc filter add dev eth1 parent : protocol ip prio 1 u32 match ip src
pp.dd.df.0/23 police rate 1024kbit burst 10kb drop flowid :
...
...
and finally:
tc filter add dev eth1 parent : protocol ip prio 2 u32 match ip src
0.0.0.0/0 police rate 256kbit burst 10kb drop flowid :
My question is, is there a way I can limit the overall speed of incoming
packets from all of those defined subnets to 1024kbps, as it seems in the
above scenario that if packets from xx.yy.zz.0/24 subnet arrive at the
speed
of 1024kbps, and at the same time packets are arriving from
pp.dd.df.0/23 at
1024kbps the overall would be 2048kbps, which I do not want.
You can use a shared meter.
... police index 1 rate ..
I will read on about the index shared meter. Hope that will do what I
need to achieve.
Any comments or suggestions on this topic are welcomed.
Another question I have is, what is the difference of the burst/buffer
being 10kb or 90kb for example? What difference would that make?
The detailed behaviour probably depends on rate estimators in kernel config.
Roughly the burst/buffer is a virtual buffer that when full will cause
further packets to be dropped until it has drained enough over time to
pass them again.
So a buffer of 10kbytes will allow first 10kbytes to flow at the rate of
the line and the next packets be shaped at the filter rate?
example:
tc filter add dev eth1 parent : protocol ip prio 2 u32 match ip src
0.0.0.0/0 police rate 256kbit burst 10kb drop flowid :
if line speed is 512 kbit, the first downloaded 10kbytes will travel at
512kbit, and the packets afterwards will flow at the speed of 256kbit.
Is that kind of correct?
If you are shaping ingress at near link speed I think smaller is better
- if you are shaping well below link speed like 1meg/100 then you can
use a bigger buffer.
Andy.
I think I got that.
Regards,
-nik
--
Когато сме щастливи, сме добри.
Но когато сме добри, не винаги сме щастливи...
-Оскар Уайлд
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
