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 ffff: > > > > > > then: > > > > tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match ip src > > xx.yy.zz.0/24 police rate 1024kbit burst 10kb drop flowid ffff: > > tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match ip src > > pp.dd.df.0/23 police rate 1024kbit burst 10kb drop flowid ffff: > > ... > > ... > > and finally: > > > > tc filter add dev eth1 parent ffff: protocol ip prio 2 u32 match ip src > > 0.0.0.0/0 police rate 256kbit burst 10kb drop flowid ffff: > > > > > > 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 ffff: protocol ip prio 2 u32 match ip src 0.0.0.0/0 police rate 256kbit burst 10kb drop flowid ffff: 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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
