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. 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. 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? Regards, -Nikolay Kichukov
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.> > 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 ......> > 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. 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.
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 -- Когато сме щастливи, сме добри. Но когато сме добри, не винаги сме щастливи... -Оскар Уайлд
Nikolay Kichukov wrote:>>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?Ingress shaping is a kludge - you can do alot better than doing nothing, but depending on the speed/buffer size of the link and your requirements you will need to sacrifice alot more than 5%. 20% for a start and depending on traffic upto 50% - ouch. Andy.