[LARTC] tc ingress policing with multiple subnets

[LARTC] tc ingress policing with multiple subnets

[Nikolay Kichukov]

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


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc ingress policing with multiple subnets

[Andy Furniss]

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.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [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

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

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] tc ingress policing with multiple subnets

[Andy Furniss]

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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc