--pgp-sign-Multipart_Mon_Apr_11_19:14:11_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "ns" == Nicolas Saurbier <Nicolas.Saurbier@concept04.de> writes:

    ns> But http from "webserver" on rtk2 must work with 100Mbit.  So
    ns> when I set bandwidth to 1Mbit on rtk0, I have only 1Mbit to
    ns> "webserver" (as expected). Is there any way to get this issue
    ns> solved?

sure.  Here's what I use:

altq on $coloswitch hfsc bandwidth 100Mb \
        queue { colo-i, colo-lan }
queue colo-i bandwidth 384000b hfsc( upperlimit 384000b ) \
        { shardy-si, phar-si, ... }
  queue shardy-si               bandwidth   12% { shardy-si-b, shardy-si-rt }
    queue shardy-si-b         bandwidth   60% hfsc( red )
    queue shardy-si-rt        bandwidth   40% hfsc( red )
   queue phar-si                 bandwidth   12% { phar-si-b, phar-si-rt }
    queue phar-si-b           bandwidth   60% hfsc( red )
    queue phar-si-rt          bandwidth   40% hfsc( red )
   .
   .
   .
  queue colo-o-si               bandwidth   12% { colo-o-si-b, colo-o-si-rt }
    queue colo-o-si-b         bandwidth   60% hfsc( red, default )
    queue colo-o-si-rt        bandwidth   40% hfsc( red )

queue colo-lan        bandwidth 99616000b hfsc( red )

The key is to use HFSC's ``upperlimit'' curve to cap some subset of
your traffic to something comfortably below your downstream bandwidth.
Use PF to assign all traffic that came fro DSL to a queue under this
parent based on its IP addresses.  Underneath that
``upperlimit''-curveed parent queue, you can create whatever
complicated link sharing policy you like for your downstream traffic,
and queues can borrow unused bandwidth from each other and such.

Then you can use PF to classify web server traffic into the 'colo-lan'
queue where it won't be capped.

You probably want to make colo-lan your 'default' queue.  I make the
rate-limited other/bulk queue 'default' so it's easier for me to catch
problems with traffic I'm not classifying like OSPF or Appletalk, or
typos in queue names, that sort of thing.  I think ARP im-at replies
will go into that 'default' queue, too, which caused me some very
interesting problems when it was taking heavy loss. :)

--pgp-sign-Multipart_Mon_Apr_11_19:14:11_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iQCVAwUAQlsEw4nCBbTaW/4dAQLYQwQAhGDTUH1G1vO60QxUha5b9iaAO6y/MxYV
c5e99DuA+kZoRRPwpGH5KfgQpSYJ0hw5tvr9atuiuj5jv3n1jPGVPeYqD1IBUkAN
5j4rMoNcw+v7/Ln6tmQW1PXhBGg1I50u/9Wj5FlCN/tXVmO3ElRe3mN6o76rQEBc
bOjVjf6zeA8=
=9wO7
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Apr_11_19:14:11_2005-1--