--pgp-sign-Multipart_Wed_Dec_22_21:50:01_2004-1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>>>>> "ddg" =3D=3D Daniel Dias Gon=E7alves <ddg@yan.com.br> writes:

   ddg> want to limit IP 192.168.0.1 has 256kbps, IP 192.168.0.2 has
   ddg> 64kbps. This is possible?

yeah, sorta.  you can use CBQ without 'borrow' but it is very inexact.
In fact, I can't get CBQ 'borrow' to work at all so very little more
than exactly what you describe is possible in my experience.

You can use it on your inside interface to cap downstream.  ALTQ was
not meant to be used this way, but with TCP congestion control it does
help to do this.

i am using sometihng like:

map outside0 0/0 -> 0/32

interface inside0 bandwidth 200000000 cbq
class cbq inside0 root NULL red pbandwidth 100
class cbq inside0 innurnet root red exactbandwidth 384000
class cbq inside0 def root red exactbandwidth 199000000
class cbq inside0 everything-0 def red pbandwidth 40 borrow
class cbq inside0 control-c def red pbandwidth 2 control
class cbq inside0 everything-1 def red pbandwidth 40 borrow default

filter6 inside0 innurnet 3ffe:401d:203a::/48 0 ::0/0 0 0
filter6 inside0 everything-0 3ffe:401d:203a::/48 0 3ffe:401d:203a::/48 0 0
filter inside0 innurnet 192.168.0.0 netmask 255.255.0.0 0 0 netmask 0 0=20
0
filter inside0 everything-0 192.168.0.0 netmask 255.255.0.0 0 192.168.0.0 n=
etmask 255.255.0.0 0 0

because i can't get CBQ borrowing to work, i set the token buffer much
bigger than the interface bandwidth.  Otherwise, internal traffic
would be capped at (100Mbit/s - 384kbit/s).  I think it's still wrong,
but it sorta works.

This is close to what I actually use.  There's a lot of
trial-and-error cruft in there.  You'll have to modify it to make two
different caps for different downstream destinations.

Another thing you might try is HFSC with a link-sharing curve of 0 and
a real-time curve of <your cap>.  That is supposed to work to do
capping, but I never tried it.

I'm going to try the altq patch that goes with security/pflkm next,
but haven't finished so can't report experience.  It's a port of
OpenBSD's ALTQ, so it is closer to KAME and has much more features, in
particular you can say 'hfsc( red, upperlimit xxxb )' which I think
will let you make several classes underneath a non-work-conserving
bandwidth-capping class that can borrow from each other---very useful
for this abusing of ALTQ to shape incoming traffic.  There is no
upperlimit service curve in NetBSD ALTQ, so I can't try that yet.

here is what i read about HFSC:

 http://www.csl.sony.co.jp/~kjc/software/TIPS.txt

The version described is neither the NetBSD version nor the
OpenBSD/KAME version, but the HFSC fundamentals are there.

You can't separate the two NATed addresses for the upstream direction
with NetBSD ALTQ.  The ALTQ classifier runs right before the interface
output queue.  You'll have to use the pflkm ALTQ to do that, which
does classifying a different way.  There is still a problem with
tunnels I think, but you can classify traffic into queues before NAT
so it solves your problem.

--=20
The auditing that is conducted on slot machine software in the U.S. is
significantly more meticulous than what is done to voting software.
		-- Bruce Schneier

--pgp-sign-Multipart_Wed_Dec_22_21:50:01_2004-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (NetBSD)

iQCVAwUAQcoyZInCBbTaW/4dAQId+wP7BYz6Kum7cdNnaSJUeJfa2CsyGh3WgH8A
Klh5u7pPXLuvxuNVXo+x4NwGcaSvSDsOwXk7L9YZUZ7/ohSplWFapSlmv74zpyRo
uS0MesDWDMQU3sHWYw4HE5RUYwq9XO4Aws4o4O5kWrzWBk/fqvcTqGSP+mph8lMO
QUmX1gECN60=
=Urkd
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Dec_22_21:50:01_2004-1--