I'm no pro (and I've never seen a connection that had a transfer cap
applied to upstream+downstream), but if I was limited to 512 kb/s up+down,
I'd want to:
1) Prioritize ACKs to limit getting hammered with retransmits
2) Throttle guests tightly but allow them to borrow from other queues; not
too much, as if we allow 256k upstream we're probably getting back a lot
more bottlenecked up on the downstream. PF can't control how much data hits
the downstream except by limiting the upstream.
3) Have an upstream router that supports ECN/RED :P
4) Use the fancy HFSC scheduler! (huzzah)
For example:
altq on $ext_if bandwidth 128Kb hfsc queue { ack, dns, hipri, def, guest1,
guest2 }
queue ack bandwidth 60% priority 6 qlimit 200 hfsc (realtime 30% ecn)
queue dns bandwidth 10% priority 5 qlimit 200 hfsc (realtime 20% ecn)
queue hipri bandwidth 10% priority 4 qlimit 150 hfsc (realtime 20% ecn)
queue def bandwidth 10% priority 2 qlimit 100 hfsc (realtime 20% ecn
default)
queue guest1 bandwidth 5% priority 0 qlimit 50 hfsc (upperlimit 15% red)
queue guest2 bandwidth 5% priority 0 qlimit 50 hfsc (upperlimit 15% red)
block in all
block out on $ext_if
block out log on $int_if
block out log on $guest1_if
block out log on $guest2_if
block out log on $dmz_if
# Now to allow some traffic. For example, let's allow DNS traffic out unto
the internets at priority 5, and its TCP ACKs at priority 6:
pass out on $ext_if proto {tcp udp} from any to any port 53 queue (dns, ack)
Haven't tried it, but I imagine that that ruleset beats the hell out of
plain old filtering from the end users' perspective. You'll obviously need
to add all the packet filtering rules for it to work, but that would be my
first shot at the queueing.
Note that all the queues except guest1 and guest2 are allowed to borrow
bandwidth up to 100% of the 256kb queue, but guest1 and guest2 are
restricted to a max of 15% of that (so the 2 guest nets can do a max of 30%
of total outbound).
Note also that we're limiting outbound traffic to 128kb because outbound +
inbound are rate limited to 512k. Might actually have to reduce that a
little to speed things up once it gets congested; play with it and see!
Also, there's a high probability that something about this is wrong/stupid,
as it's untested, but I'm sure someone will correct me. ;)
On Tue, Nov 20, 2012 at 5:45 PM, Mikolaj Kucharski
<miko...@kucharski.name>wrote:
> Hi,
>
> Searched for this for a while. Found below old post, without answer. Is
> this actually possible to setup that way?
>
>
> > From http://marc.info/?l=openbsd-pf&m=112015092309886&w=2
> >
> > List: openbsd-pf
> > Subject: Altq - limiting traffic among multiple interfaces
> > From: Jonathan Camenisch <alaythia () gmail ! com>
> > Date: 2005-06-30 14:15:55
> > Message-ID: fd5fdde005063007153fc4c2c2 () mail ! gmail ! com
> >
> > In our organization, I'd like to use Altq to keep any one process
> > (download or whatever) from hogging bandwidth and degrading
> > performance for others. It's more complicated than I expected, though,
> > and I haven't been able to find an example that's much like my
> > environment (I'd be glad to publish mine if I could get it working
> > well). Here's the layout:
> >
> > Office (internal) subnet DMZ
> > | /
> > [fxp0] [fxp1]
> > Internet -------[fxp4]OpenBSD/pf firewall
> > [fxp2] [fxp3]
> > | \
> > Guest class 1 subnet Guest class 2 subnet
> >
> > We have sort of a conference center, so we're providing access for
> > guests as well as offices. Hence all the subnets. We also host some of
> > our own web sites on the DMZ.
> >
> > Now to make it more complicated, our fractional "T1" provides 512Kb of
> > *total* bandwidth. That is, the total of upload *and* download
> > bandwidth can never exceed 512Kb.
> >
> > Ideally, I would like to set up a single 512k queue and divy it up
> > (with cbq) among all traffic that passes in or out of fxp4, regardless
> > of which interface it exits. (I'd really like to allow borrowing among
> > all directions.)
> >
> > But as far as I know, there's no way to do exactly that. What I'm
> > hoping someone could suggest is, what's the best I can do? That is,
> > how can I get the best utilization out of my limited connection while
> > preventing anything from hogging it?
> >
> > Forgive me if I'm overlooking information that's already available.
> > I'm afraid my brain's gotten a little scrambled trying to adapt the
> > altq model to this scenario. Thank you for your time!
> >
> > Jonathan
>
>
> --
> best regards
> q#
