[LARTC] tc ingress policing with multiple subnets

[Nikolay Kichukov]

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

-- 
Когато сме щастливи, сме добри.
Но когато сме добри, не винаги сме щастливи...
-Оскар Уайлд