Thank you all for your reply. Breen, no - I really do not have, so
limited bandwith like described below. However each time I started to
download not even being close to my maximum bandwith, both ingress and
egress traffic dropped for a while, maybe for 1 - 2 seconds then
recovered, and again dropped, again recovered, so on, so forth.
I could limit a lot upload traffic, by changing bandwidth keyword on
external interface for priq scheduler. That worked to see more stable
internet, however I waneted to limit download and not upload.
I have many internal interfaces (like the person in quoted post). That's
why I've asked, is that setup possible as it would let me do, in similar
way, what I wanted. However your posts pointed me in different
direction, and I think I've solved my problem.
It looks that performance of ppp(8)+pppoe(8)+tun(4) vs pppoe(4) has huge
difference with higher speeds, and as I never dealt with ADSL before in
my life, I did not know that. I've look at:
http://www.openbsd.org/faq/faq6.html#PPP
when I initially needed to setup my new internet connection and somehow
didn't picked up that userland pppoe will be slower.
After Stuart's email I've looked again, how to setup pppoe(4) and it
works hell of a lot better. No more ingress (and egress) stalls.
Then found some old post[#ref1] which mentions performance difference
between kernel and userland version of PPPoE.
Could faq6.html#PPP have a small note (if that make sense) that initial
PPPoE setup one could choose as userland pppoe(8), as it is easier to
debug any issues and then as a permanent solution switch to kernel
ppppoe(4) because of better performance with higher connection speeds
of DSL line?
And for the records, as easy as it is. OpenBSD kernel PPPoE
configuration for Eircom:
# /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE pppoedev vr0 authproto chap \
authname [email protected] authkey broadband1 \
description "pppoe uplink"
dest 0.0.0.1
up
!/sbin/route -nq add default -ifp pppoe0 0.0.0.1
References
1. http://forums.whirlpool.net.au/archive/481579
On Tue, Nov 20, 2012 at 10:45:05PM +0000, Mikolaj Kucharski 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#
