Re: ALTQ
Stuart Henderson wrote:
On 2009/04/14 17:37, Helmut Schneider wrote:
What I want to do is to assign the default queue the whole bandwith
(100%) and let e.g. http borrow 5Mb. As I do not know the connection
speed (might be 1GB or 100Mb within the local LAN, but might also be
34Mb for the internet) I guess I need to mix absolute values and
percentages which I currently fail to implement.
you can't really use altq well where you don't know the connection speed.
to work properly when the line is full, you need to restrict it to the
lowest speed your connection might be running at, and take into account
any other users (unless all traffic on the line is going through this
box).
Actually I do traffic shaping at the border router but I was looking for a
more sophisticated solution to restrict bandwidth for certain services at
the host itself (e.g. to limit ftp servers' upload speed to the internet).
altq running on the proxy may well not be the correct tool for the
job here. maybe squid connection pools, or something else, are more
appropriate. or maybe altq on another machine/cluster (e.g. a
firewall) sitting between the router and the entire network might
be a good choice.
I'm currently thinking about the latter, to put it between the router and
the firewall as a pure traffic shaping solution. Meanwhile I use the
following values:
altq on $extIF cbq bandwidth 1000Mb queue { std, traf_ext }
queue std bandwidth 990Mb cbq(default borrow)
queue traf_ext bandwidth 10Mb { traf_ext_ftp, traf_ext_http }
queue traf_ext_ftp bandwidth 50% cbq(borrow)
queue traf_ext_http bandwidth 50% cbq(borrow)
Thanks to both of you, Helmut
--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn
Re: ALTQ
On Tue, 14 Apr 2009 17:37:42 +0200
"Helmut Schneider" wrote:
> From: "Robert"
> > On Tue, 14 Apr 2009 15:39:48 +0200
> > "Helmut Schneider" wrote:
> >
> >> From: "Robert"
> >>> "Helmut Schneider" wrote:
> My proxy has one single GB interface and is connected to the
> internet using a E3-line (34Mb). I want to shape http traffic to
> 5Mb/s. How?
>
> Something like:
>
> altq on $extIF cbq bandwidth 100% queue { default, http_traf }
> queue default bandwidth 100% cbq(default borrow)
> queue http_traf bandwidth 5Mb cbq(borrow)
>
> What is the correct syntax?
>
> Thanks, Helmut
> >>>
> >>> This is explained (with an example you can adapt) in the PF FAQ.
> >>> http://www.openbsd.org/faq/pf/queueing.html
> >>
> >> No, it's not. The FAQ talks about two interfaces, I only do have
> >> one single interface. I also did not find an example where the
> >> default queue may use 100% percent and HTTP may use lets say 5Mb
> >> from that amount.
> >>
> >> If I'm wrong please point me to the specific location.
> >
> > Doesn't this section explain how to do it?
> > http://www.openbsd.org/faq/pf/queueing.html#assign
>
> Well, if then I do not understand it. The section states:
>
> altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
> queue std bandwidth 500Kb cbq(default)
> queue ftp bandwidth 1.5Mb
>
> What I want to do is to assign the default queue the whole bandwith
> (100%) and let e.g. http borrow 5Mb. As I do not know the connection
> speed (might be 1GB or 100Mb within the local LAN, but might also be
> 34Mb for the internet) I guess I need to mix absolute values and
> percentages which I currently fail to implement.
>
> What I tried:
>
> altq on $extIF cbq bandwidth 100% queue { default, http_traf }
> queue default bandwidth 100% cbq(default borrow)
> queue [default_]http_traf bandwidth 5Mb cbq(borrow)
>
> which does not work:
>
> # pfctl -nf /etc/pf.conf
> pfctl: the sum of the child bandwidth higher than parent "root_bge1"
> #
100% + 5Mb > 100%
All children have to fit into the parent.
(I think its a bad idea to mix % and Mb limits in the same tier of
child-queues.)
And "borrow" allows the child-queue to use more bandwidth than was
defined, if it is available. As your interface has more bandwidth than
your 34Mbit to the internet the queue won't have any effect.
If you want 'http-traf' to get 5Mb max omit the "borrow".
If you only queue traffic to your E3, just set the parent to 34Mb.
- Robert
Re: ALTQ
On 2009/04/14 17:37, Helmut Schneider wrote: > What I want to do is to assign the default queue the whole bandwith > (100%) and let e.g. http borrow 5Mb. As I do not know the connection > speed (might be 1GB or 100Mb within the local LAN, but might also be > 34Mb for the internet) I guess I need to mix absolute values and > percentages which I currently fail to implement. you can't really use altq well where you don't know the connection speed. to work properly when the line is full, you need to restrict it to the lowest speed your connection might be running at, and take into account any other users (unless all traffic on the line is going through this box). there are some other things that might apply: - there may be a disconnect between incoming and outgoing traffic, maybe the proxy fetches the object at whatever speed it can and buffers it - you might not want to throttle sending cached objects to the lan, only the internet bandwidth - altq only restricts the speed of outbound traffic altq running on the proxy may well not be the correct tool for the job here. maybe squid connection pools, or something else, are more appropriate. or maybe altq on another machine/cluster (e.g. a firewall) sitting between the router and the entire network might be a good choice.
Re: ALTQ
From: "Robert"
On Tue, 14 Apr 2009 15:39:48 +0200
"Helmut Schneider" wrote:
From: "Robert"
"Helmut Schneider" wrote:
My proxy has one single GB interface and is connected to the
internet using a E3-line (34Mb). I want to shape http traffic to
5Mb/s. How?
Something like:
altq on $extIF cbq bandwidth 100% queue { default, http_traf }
queue default bandwidth 100% cbq(default borrow)
queue http_traf bandwidth 5Mb cbq(borrow)
What is the correct syntax?
Thanks, Helmut
This is explained (with an example you can adapt) in the PF FAQ.
http://www.openbsd.org/faq/pf/queueing.html
No, it's not. The FAQ talks about two interfaces, I only do have one
single interface. I also did not find an example where the default
queue may use 100% percent and HTTP may use lets say 5Mb from that
amount.
If I'm wrong please point me to the specific location.
Doesn't this section explain how to do it?
http://www.openbsd.org/faq/pf/queueing.html#assign
Well, if then I do not understand it. The section states:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std bandwidth 500Kb cbq(default)
queue ftp bandwidth 1.5Mb
What I want to do is to assign the default queue the whole bandwith (100%)
and let e.g. http borrow 5Mb. As I do not know the connection speed (might
be 1GB or 100Mb within the local LAN, but might also be 34Mb for the
internet) I guess I need to mix absolute values and percentages which I
currently fail to implement.
What I tried:
altq on $extIF cbq bandwidth 100% queue { default, http_traf }
queue default bandwidth 100% cbq(default borrow)
queue [default_]http_traf bandwidth 5Mb cbq(borrow)
which does not work:
# pfctl -nf /etc/pf.conf
pfctl: the sum of the child bandwidth higher than parent "root_bge1"
#
Re: ALTQ
On Tue, 14 Apr 2009 15:39:48 +0200
"Helmut Schneider" wrote:
> From: "Robert"
> > "Helmut Schneider" wrote:
> >> My proxy has one single GB interface and is connected to the
> >> internet using a E3-line (34Mb). I want to shape http traffic to
> >> 5Mb/s. How?
> >>
> >> Something like:
> >>
> >> altq on $extIF cbq bandwidth 100% queue { default, http_traf }
> >> queue default bandwidth 100% cbq(default borrow)
> >> queue http_traf bandwidth 5Mb cbq(borrow)
> >>
> >> What is the correct syntax?
> >>
> >> Thanks, Helmut
> >
> > This is explained (with an example you can adapt) in the PF FAQ.
> > http://www.openbsd.org/faq/pf/queueing.html
>
> No, it's not. The FAQ talks about two interfaces, I only do have one
> single interface. I also did not find an example where the default
> queue may use 100% percent and HTTP may use lets say 5Mb from that
> amount.
>
> If I'm wrong please point me to the specific location.
>
> Thanks, Helmut
Doesn't this section explain how to do it?
http://www.openbsd.org/faq/pf/queueing.html#assign
- Robert
Re: ALTQ
From: "Robert"
"Helmut Schneider" wrote:
My proxy has one single GB interface and is connected to the internet
using a E3-line (34Mb). I want to shape http traffic to 5Mb/s. How?
Something like:
altq on $extIF cbq bandwidth 100% queue { default, http_traf }
queue default bandwidth 100% cbq(default borrow)
queue http_traf bandwidth 5Mb cbq(borrow)
What is the correct syntax?
Thanks, Helmut
This is explained (with an example you can adapt) in the PF FAQ.
http://www.openbsd.org/faq/pf/queueing.html
No, it's not. The FAQ talks about two interfaces, I only do have one single
interface. I also did not find an example where the default queue may use
100% percent and HTTP may use lets say 5Mb from that amount.
If I'm wrong please point me to the specific location.
Thanks, Helmut
Re: ALTQ
On Tue, 14 Apr 2009 14:23:48 +0200
"Helmut Schneider" wrote:
> Hi,
>
> My proxy has one single GB interface and is connected to the internet
> using a E3-line (34Mb). I want to shape http traffic to 5Mb/s. How?
>
> Something like:
>
> altq on $extIF cbq bandwidth 100% queue { default, http_traf }
> queue default bandwidth 100% cbq(default borrow)
> queue http_traf bandwidth 5Mb cbq(borrow)
>
> What is the correct syntax?
>
> Thanks, Helmut
>
This is explained (with an example you can adapt) in the PF FAQ.
http://www.openbsd.org/faq/pf/queueing.html
- Robert
Re: altq priq Anomaly (Solved)
On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: > On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > On 2007/07/20 15:20, Daniel Melameth wrote: > > > then go back to the broken behavior sometime later. A reboot of the box > > > or > > > removing altq is the only way to resolve the issue, temporarily. I've > > > tried > > > both priq and cbq, adjusting tbrsize, recompiling the kernel with a higher > > > HZ value and using different hardware and different Internet connections, > > > but the issue persists. > > > > Try a snapshot, i386 moved to the new timecounter code after 4.1. > > > > Though I note there is also an XXX about variable cpu frequency (in > > sys/altq/altq_subr.c) which might affect you if you adjust cpu speed > > (manually or by apmd). > > Thanks for taking the time to reply. I can't readily do a snapshot > now, but since I am using apmd, I'll try this avenue first and see > what happens. Thanks to Stuart's review of the altq code, I have, finally, resolved this issue which has affected me for years. Disabling apmd did not resolve the issue, but disabling the Dynamically Switchable setting for CPU Frequency in the BIOS appears to have addressed this problem. I have been using the system for a couple of months now and altq has been very solid.
Re: altq priq Anomaly
On Wed, Aug 01, 2007 at 12:55:15PM +0100, Stuart Henderson wrote: > On 2007/07/30 17:33, Can Erkin Acar wrote: > > > > The problem with this diff is that it assumes an ADSL link. > > While 'vcmux' is obviously ADSL terminology, I assume > > having 'pppoe' or 'bridge' would confuse others trying to > > use non-adsl pppoe connections or even real bridges. > > That's a very fair point. I was aiming for a balance of accuracy > and simplicity with the keyword names, and might have gone too far > in the direction of simplicity (though the listing in the manual > is done in more detail). > > > While altq is not my area, I think the diff would be > > more useful if it allowed an 'overhead' and a 'scale' > > to be set on an interface. You could then document suitable > > values for commonly used setups (pppoe/vcmux/whatever). > > There are a finite number of adaptations which would be really useful, > so I think that adds unnecessary complexity to the configuration > language, and it's easier to see what's going on when this is expressed > directly in C than by listing magic numbers in an already-long manual > page. With the framework in place it's simple to see where additions > should go. I am really not sure about this. I would prefer to pass the 'magic' parameters to the kernel, and put the tables into pfctl. That way the kernel and pfctl do not have to match exactly, and you could fine tune in userland, without changing the kernel. > How would you feel about it with more descriptive keywords? Descriptive keywords would be better, but see the above comment. This way you can do both.
Re: altq priq Anomaly
On 2007/07/30 17:33, Can Erkin Acar wrote: > > The problem with this diff is that it assumes an ADSL link. > While 'vcmux' is obviously ADSL terminology, I assume > having 'pppoe' or 'bridge' would confuse others trying to > use non-adsl pppoe connections or even real bridges. That's a very fair point. I was aiming for a balance of accuracy and simplicity with the keyword names, and might have gone too far in the direction of simplicity (though the listing in the manual is done in more detail). > While altq is not my area, I think the diff would be > more useful if it allowed an 'overhead' and a 'scale' > to be set on an interface. You could then document suitable > values for commonly used setups (pppoe/vcmux/whatever). There are a finite number of adaptations which would be really useful, so I think that adds unnecessary complexity to the configuration language, and it's easier to see what's going on when this is expressed directly in C than by listing magic numbers in an already-long manual page. With the framework in place it's simple to see where additions should go. How would you feel about it with more descriptive keywords?
Re: altq priq Anomaly
On Fri, Jul 27, 2007 at 06:53:27PM -0600, Daniel Melameth wrote: > On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: > > On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > > On 2007/07/20 15:20, Daniel Melameth wrote: > > > > then go back to the broken behavior sometime later. A reboot of the > > > > box or > > > > removing altq is the only way to resolve the issue, temporarily. I've > > > > tried > > > > both priq and cbq, adjusting tbrsize, recompiling the kernel with a > > > > higher > > > > HZ value and using different hardware and different Internet > > > > connections, > > > > but the issue persists. > > > > > > Try a snapshot, i386 moved to the new timecounter code after 4.1. > > > > > > Though I note there is also an XXX about variable cpu frequency (in > > > sys/altq/altq_subr.c) which might affect you if you adjust cpu speed > > > (manually or by apmd). > > > > > > > Full detail on the issue is available from my gnats post at > > > > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and > > > > TCP > > > > > > For this you might like to try a diff of mine and report back > > > (http://spacehopper.org/openbsd/altq_tbradapt.diff). > > > It won't help the other problem though. > > > > Thanks for taking the time to reply. I can't readily do a snapshot > > now, but since I am using apmd, I'll try this avenue first and see > > what happens. I also went ahead and incorporated your diffs into my > > currently running 4.1-stable and it appears to be working quite well, > > but I'm not certain if I'm piloting these changes the correct way--so > > if there's an ideal way you'd recommend piloting this, let me know. > > Regardless, I'll monitor the result of these diffs this week and give > > you a heads up at the end of the week. > > Stuart, > > I did some simple piloting of your diffs and they work quite nicely. > The details: > > Without altq, I get a fairly consistent roundtrip latency of 58ms to a > known good host when there is no congestion--and when the upstream is > saturated, latency to the same host goes up to ~220ms. If I use altq > without your diffs and specify my maximum upload bandwidth of 896Kb, > as expected the overhead of PPPoE tramples this and I still get ~220ms > under saturation even with a high priority queue. In order to get > decency latency in this case, I have to artificially estimate a > bandwidth of ~716Kb--and this provides for a high priority queue > latency of ~68ms while saturated, which is pretty good. > > With your diffs though, not only do I get ~68ms for a high priority > queue while using a bandwidth of 896Kb on a saturated connection, but > my maximum upload speed is, consistently, a bit higher as well when > compared to using a bandwidth of 716Kb without your diffs. I > continued to pilot your diffs further by seeding and downloading > multiple torrents simultaneously--to more heavily expose small TCP > ACKs to the stream--and I continued to get these consistently good > results. > > I have been using your diffs for almost a week now with nary an issue. > So, my next question is: > > HOW DO WE GET YOUR GREAT DIFFS INTO -CURRRENT OR A SNAPSHOT? The problem with this diff is that it assumes an ADSL link. While 'vcmux' is obviously ADSL terminology, I assume having 'pppoe' or 'bridge' would confuse others trying to use non-adsl pppoe connections or even real bridges. While altq is not my area, I think the diff would be more useful if it allowed an 'overhead' and a 'scale' to be set on an interface. You could then document suitable values for commonly used setups (pppoe/vcmux/whatever).
Re: altq priq Anomaly
On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: > On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > On 2007/07/20 15:20, Daniel Melameth wrote: > > > then go back to the broken behavior sometime later. A reboot of the box > > > or > > > removing altq is the only way to resolve the issue, temporarily. I've > > > tried > > > both priq and cbq, adjusting tbrsize, recompiling the kernel with a higher > > > HZ value and using different hardware and different Internet connections, > > > but the issue persists. > > > > Try a snapshot, i386 moved to the new timecounter code after 4.1. > > > > Though I note there is also an XXX about variable cpu frequency (in > > sys/altq/altq_subr.c) which might affect you if you adjust cpu speed > > (manually or by apmd). > > > > > Full detail on the issue is available from my gnats post at > > > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and TCP > > > > For this you might like to try a diff of mine and report back > > (http://spacehopper.org/openbsd/altq_tbradapt.diff). > > It won't help the other problem though. > > Thanks for taking the time to reply. I can't readily do a snapshot > now, but since I am using apmd, I'll try this avenue first and see > what happens. I also went ahead and incorporated your diffs into my > currently running 4.1-stable and it appears to be working quite well, > but I'm not certain if I'm piloting these changes the correct way--so > if there's an ideal way you'd recommend piloting this, let me know. > Regardless, I'll monitor the result of these diffs this week and give > you a heads up at the end of the week. Stuart, I did some simple piloting of your diffs and they work quite nicely. The details: Without altq, I get a fairly consistent roundtrip latency of 58ms to a known good host when there is no congestion--and when the upstream is saturated, latency to the same host goes up to ~220ms. If I use altq without your diffs and specify my maximum upload bandwidth of 896Kb, as expected the overhead of PPPoE tramples this and I still get ~220ms under saturation even with a high priority queue. In order to get decency latency in this case, I have to artificially estimate a bandwidth of ~716Kb--and this provides for a high priority queue latency of ~68ms while saturated, which is pretty good. With your diffs though, not only do I get ~68ms for a high priority queue while using a bandwidth of 896Kb on a saturated connection, but my maximum upload speed is, consistently, a bit higher as well when compared to using a bandwidth of 716Kb without your diffs. I continued to pilot your diffs further by seeding and downloading multiple torrents simultaneously--to more heavily expose small TCP ACKs to the stream--and I continued to get these consistently good results. I have been using your diffs for almost a week now with nary an issue. So, my next question is: HOW DO WE GET YOUR GREAT DIFFS INTO -CURRRENT OR A SNAPSHOT?
Re: altq priq Anomaly
On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: On 2007/07/20 15:20, Daniel Melameth wrote: > then go back to the broken behavior sometime later. A reboot of the box or > removing altq is the only way to resolve the issue, temporarily. I've tried > both priq and cbq, adjusting tbrsize, recompiling the kernel with a higher > HZ value and using different hardware and different Internet connections, > but the issue persists. Try a snapshot, i386 moved to the new timecounter code after 4.1. Though I note there is also an XXX about variable cpu frequency (in sys/altq/altq_subr.c) which might affect you if you adjust cpu speed (manually or by apmd). > Full detail on the issue is available from my gnats post at > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and TCP For this you might like to try a diff of mine and report back (http://spacehopper.org/openbsd/altq_tbradapt.diff). It won't help the other problem though. Thanks for taking the time to reply. I can't readily do a snapshot now, but since I am using apmd, I'll try this avenue first and see what happens. I also went ahead and incorporated your diffs into my currently running 4.1-stable and it appears to be working quite well, but I'm not certain if I'm piloting these changes the correct way--so if there's an ideal way you'd recommend piloting this, let me know. Regardless, I'll monitor the result of these diffs this week and give you a heads up at the end of the week. The only breakage I've noticed so far appears to be related to pfstat which reports the following (and I assume this is related to the new headers, but I haven't looked into it yet): ioctl: DIOCGETALTQS: Permission denied pf_query: query_queues() failed Thanks again Stuart.
Re: altq priq Anomaly
A recompile of pfstat has addressed this. On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: Thanks for taking the time to reply. I can't readily do a snapshot now, but since I am using apmd, I'll try this avenue first and see what happens. I also went ahead and incorporated your diffs into my currently running 4.1-stable and it appears to be working quite well, but I'm not certain if I'm piloting these changes the correct way--so if there's an ideal way you'd recommend piloting this, let me know. Regardless, I'll monitor the result of these diffs this week and give you a heads up at the end of the week. The only breakage I've noticed so far appears to be related to pfstat which reports the following (and I assume this is related to the new headers, but I haven't looked into it yet): ioctl: DIOCGETALTQS: Permission denied pf_query: query_queues() failed
Re: altq priq Anomaly
On 2007/07/20 15:20, Daniel Melameth wrote: > then go back to the broken behavior sometime later. A reboot of the box or > removing altq is the only way to resolve the issue, temporarily. I've tried > both priq and cbq, adjusting tbrsize, recompiling the kernel with a higher > HZ value and using different hardware and different Internet connections, > but the issue persists. Try a snapshot, i386 moved to the new timecounter code after 4.1. Though I note there is also an XXX about variable cpu frequency (in sys/altq/altq_subr.c) which might affect you if you adjust cpu speed (manually or by apmd). > Full detail on the issue is available from my gnats post at > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and TCP For this you might like to try a diff of mine and report back (http://spacehopper.org/openbsd/altq_tbradapt.diff). It won't help the other problem though.
Re: altq chokes on userland pppoe
On Fri, May 11, 2007 at 09:42:47PM +0200, Tobias Freitag wrote: > Hi list, > > > the altq setup on my dsl line seems to be caught in a vicious cycle. Traffic > goes up and down in a regular cycle of about 4 seconds when it convergates > towards the specified limit. A diagram of sent bytes over time (in seconds) > is attached. (red=working state, green=choked state, blue=bandwidth limit) Hi, Attachments are stripped from the mailing list. Can you put your diagram on a Web page? Thanks, ==ml -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com On 5/4/2007, the TSA kept 3 pairs of my soiled undies "for security reasons."
Re: altq chokes on userland pppoe
On Saturday, 12. May 2007 14:26:54 Michael W. Lucas wrote: > Attachments are stripped from the mailing list. Can you put your > diagram on a Web page? Done: http://praxis.ath.cx/altq-pppoe.gif
Re: altq pppoe hack
On 2006/12/03 14:07, Tony Sarendal wrote: > Quick hack to make altq handle pppoe/llcsnap links better. works for me Tony (I've been using it since you posted to tech@, with 832Kb bw set on an 832Kb-up pppoe).
Re: altq on 2 interface
On 2006/11/08 21:56, Reza Muhammad wrote:
> My rule set still not working, as i'm expected to
> limit outgoing and incoming traffic pass to my pf
> machine act as an bridge .
..
> pass out log on xl1 from 172.16.0.228 to 202.57.14.1
> keep state flags S/SA queue (int_out)
this creates a state for traffic from 172.16.0.228 and it's
responses. traffic matching the state is tagged with the queue
name int_out. only traffic sent out of xl1 is queued, there is
no matching queue for xl2 so it's unrestricted on xl2.
> pass out log on xl2 from 202.57.14.1 to 172.16.0.228
> keep state flags S/SA queue (int_in)
this creates a state for traffic from 202.57.14.1 and it's
responses. traffic matching the state is tagged with the queue
name int_in. only traffic sent out of xl2 is queued, there is
no matching queue for xl1 so it's unrestricted on xl2.
I think you want this instead: (not tested beyond checking
that the syntax is valid, but I think it should work).
-- -- -- -- -- -- --
altq on xl1 bandwidth 100% cbq queue {int,dflt}
queue int on xl1 bandwidth 3Mb
queue dflt on xl1 bandwidth 16Kb cbq (default)
altq on xl2 bandwidth 100% cbq queue {int,dflt}
queue int on xl2 bandwidth 3Mb
queue dflt on xl2 bandwidth 16Kb cbq (default)
pass out log on xl1 from 172.16.0.228 to 202.57.14.1 \
keep state flags S/SA queue (int)
pass out log on xl2 from 202.57.14.1 to 172.16.0.228 \
keep state flags S/SA queue (int)
-- -- -- -- -- -- --
"int on xl1" and "int on xl2" are different queues, but
just referred to by "int" when you assign traffic to them.
Re: altq on 2 interface
On 2006/11/09 10:13, Stuart Henderson wrote: > this creates a state for traffic from 172.16.0.228 and it's aargh, s/it's/its/ :(
Re: ALTQ for a process running on PF box
On 07/12/2006 02:33:12 AM, Daniel Hartmeier wrote: We recently had a lenghty thread about the disadvantages (requiring separate hosts) of lacking inbound queues FWIW, I've put a separate OpenBSD host in front of my firewall/router (which has several internal nics) just for inbound queuing in order to support prioritization of voip traffic and it's been working well for several months now. (The real trick was hfsc queuing in rather than cbq. I'm sure priority based queuing would work as well.) So, in practice, the tcp rate limiting successfully throttles the sender that's on the far end of the narrow pipe. One of these days I really will do some stats to prove it works in the hopes that somebody will implement inbound queuing so I can get rid of the extra box. (Unless somebody's already planning to support inbound queuing? Hope springs eternal. :-) Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: ALTQ for a process running on PF box
On Wed, Jul 12, 2006 at 03:25:28PM +1000, Adam Clark wrote: > traffic going to hosts behing the box were showing in on pflog0, but > no traffic to 10.17.10.254 shows. If I put a log-all on a line that > matches the traffic on the $ext_if interface it shows that in deed > traffic is heading towards 10.17.10.254. Which means that even though > the internal IP address is bound to the internal interface, the internal > interface never sees traffic for 10.17.10.254 that can be filtered. > Tcpdump does not show this either > Is this true or is there a way perform what I need to do in another way? Yes, that's normal, but you're not the first one to find this surprising. :) When the host, on one interface, receives a packet with a destination IP address that matches one of the host's own IP addresses (assigned to any interface), the packet is removed from the forwarding path and dispatched to the local socket instead. The destination address of the packet can influence what local socket it is dispatched to (like when you have two different sockets bound to different addresses), or it doesn't matter at all (when you have a single socket bound to *), but the kernel doesn't simulate any passage through $int_if. If it would try to send out the packet through $int_if, that would mean writing an ethernet frame out onto $int_if's wire. The simplest solution in your case is to move the bittorrent client process onto a different host on the internal network, so inbound packets to it really pass out on $int_if. We recently had a lenghty thread about the disadvantages (requiring separate hosts) of lacking inbound queues, see http://groups.google.com/group/bit.listserv.openbsd-pf/browse_thread/thread/5de1c7731114bdae If you have to move the process to another host, maybe it's a little comforting that this is also the wise thing to do from a security perspective. In the completely hypothetical case where the process has a remotely exploitable hole, you don't risk the attacker using it to gain root on the firewall and opening up its ruleset. Daniel
Re: ALTQ, Dummynet, Dynamic Rules
On Friday, Mar 24, 2006, at 05:27 US/Pacific, Daniel Dias Gonçalves wrote: I use the following rules in the IPFW: $fwcmd add 100 pipe 13 ip from 192.168.0.0/24 to any in $fwcmd add 101 pipe 14 ip from any to 192.168.0.0/24 out $fwcmd pipe 13 config mask src-ip 0x00ff bw 150Kbit/s queue 12KBytes $fwcmd pipe 14 config mask dst-ip 0x00ff bw 150Kbit/s queue 12KBytes My question, it is possible to make the same with the PF+ALTQ? Sorry, not possible. For others: that creates a limiting queue for each IP (in 192.168.0.0/24, 256 total) in each direction (150kbit/s in, 150kbit/s out).
Re: ALTQ, Dummynet, Dynamic Rules
On Friday 24 March 2006 21:27, Daniel Dias Gonçalves wrote: > $fwcmd add 100 pipe 13 ip from 192.168.0.0/24 to any in > $fwcmd add 101 pipe 14 ip from any to 192.168.0.0/24 out > $fwcmd pipe 13 config mask src-ip 0x00ff bw 150Kbit/s queue 12KBytes > $fwcmd pipe 14 config mask dst-ip 0x00ff bw 150Kbit/s queue 12KBytes > > My question, it is possible to make the same with the PF+ALTQ? Perhaps if you explained in plain english for us non-ipfw people we too could give some answers. --- Lars Hansson
Re: ALTQ on PF for gaming
On Tue, Jun 28, 2005 at 04:52:17PM +0100, Bob wrote: > I thought the problem was that you needed to limit incoming traffic as > well as outgoing traffic. i've found that limiting incoming data by queueing on the internal "LAN-facing" interface can be very beneficial if configured correctly. for instance, RTT to my default gateway is normally 12ms. the highest download bandwidth i can realize is roughly 2650 Kb/s. if i am downloading without queueing incoming, pings to the gateway under full-tilt download hover at around 500-700ms. if i set pf to queue incoming at an altq bandwidth of around 2500 Kb/s, i do not find that i lose much in the way of potential download throughput, however under a full-tilt download, the RTT only goes to about 180-300. cutting the altq bandwidth down to about 2400 brings that down further, yielding around a 40-60ms RTT. in a situation where one is trying to use queueing to achieve a high- quality RTT across the circuit to your ISP, queueing on incoming data also could be a very important factor. naturally, a hidden factor would be whether there is a bandwidth shortage leaving the DSLAM/HeadEnd you terminate at, or any other bandwidth shortages further up the food-chain as you traverse your ISPs network. ( eg - if you are provisioned at 3Mb, but there are only a 2 T1s leaving the remote unit, and there are 40 other people on there, it is probably a good idea to be a bit more conservative... in any case, one could run pings to whatever hop on the ISP's network is most applicable, graph them (or whatever) and look. spend a day or two without being involved in large data transfers ) jared - [ openbsd 3.7 GENERIC ( jun 25 ) // i386 ]
Re: ALTQ and VoIP
Ingolf Zeiner Petersen wrote: Matt Pearce wrote: I run 1536/256 ADSL here and found that a figure or 205Kb is the upper limit for me (versus the 170Kb you have) , any more and the queue wont drop packets correctly, any less and i'm not getting the full bandwidth i'm paying for. If you have 256Kb try changing this figure and you might find you gain some extra speed. Yeah, i know that i'm not getting the max out of my connection, but if i set it to anything over 200Kbit i get more lag/delay on the connection. Thats odd, the only thing I can think of is a shoddy contention ratio or something is slightly misconfigured. One way to check what is actually going on is to continually run pfctl -sq -v , this will show you how full your queue is and how many packets have been dropped. I had a play a while ago with the qlimit but I had it added into the "altq on rl1.." line, oddly it never changed a thing and never gave an error. Since seeing your qlimit statements i've been playing with it for the past couple of days and working on tuning and found a qlimit of 1 serverly limited queues and they never saw full bandwith potential. I found a good figure for me was 10 as opposed to a standard 50. My testing of the qlimit number had me pinging a local site while uploading with Azurues and watching its graph. What where your ping-times? Another thing: i'm trying to prioritize my outgoing icmp-packets.. and if I send 4 pings i get "8 packets" in pfctl -vs rules on the rule i made. I would think that "4 packets" would be more correct? *confused* My ping times normally were 29-30ms but ranged from about 80-130ms while uploading flat out with Azureus although I found the true trial to be how well I could play games online. It turns out that it was *slightly* more laggy but not to bad on a whole. I'm not sure why you would be seeing 8 packets when you send 4 pings, I just did a test here and 4 pings definately equals 4 packets. Could this be related to you not being able to set your connection speed any higher ?? If you want email me your rules off list and i'll have a look and see if I can see any problems, sometimes a fresh set of eyes helps with simple errors. Matt.
Re: ALTQ and VoIP
Greets I have learned some very valuable and time saving procedures to assist in the deployment of VOIP when using altq over the course of the last year that can possibly help you. The greatest lesson to date is that you need to work with you ISP and have them give you readings for your line condition, twice a week for a month. Call other ISP sales departments as a prospective client and ask them to measure your line, you will likely discover some interesting things about why you are or are not getting the bandwidth you expect and why there are "seeming" inconsistencies in your altq. Often altq is not the problem. What all this means is you probably aren't getting the bandwidth you are paying for. Remember you are dealing with commodity Internet and as such all of it's inherent problems. Bob
Re: ALTQ and VoIP
Matt Pearce wrote: I run 1536/256 ADSL here and found that a figure or 205Kb is the upper limit for me (versus the 170Kb you have) , any more and the queue wont drop packets correctly, any less and i'm not getting the full bandwidth i'm paying for. If you have 256Kb try changing this figure and you might find you gain some extra speed. Yeah, i know that i'm not getting the max out of my connection, but if i set it to anything over 200Kbit i get more lag/delay on the connection. I had a play a while ago with the qlimit but I had it added into the "altq on rl1.." line, oddly it never changed a thing and never gave an error. Since seeing your qlimit statements i've been playing with it for the past couple of days and working on tuning and found a qlimit of 1 serverly limited queues and they never saw full bandwith potential. I found a good figure for me was 10 as opposed to a standard 50. My testing of the qlimit number had me pinging a local site while uploading with Azurues and watching its graph. What where your ping-times? Another thing: i'm trying to prioritize my outgoing icmp-packets.. and if I send 4 pings i get "8 packets" in pfctl -vs rules on the rule i made. I would think that "4 packets" would be more correct? *confused*
Re: ALTQ and VoIP
Ingolf Zeiner Petersen wrote:
(256Kbit/s ADSL)
altq on rl1 priq bandwidth 170Kb queue { std_out, websrv_out, web_out,
im_out, rdp_out, radio_out, ssh_out, dns_out, udp_gaming_out,
ip_telefoni_out }
I run 1536/256 ADSL here and found that a figure or 205Kb is the upper
limit for me (versus the 170Kb you have) , any more and the queue wont
drop packets correctly, any less and i'm not getting the full bandwidth
i'm paying for. If you have 256Kb try changing this figure and you
might find you gain some extra speed.
queue std_out priq(default red) qlimit 1
queue websrv_outpriority 2 qlimit 1
queue rdp_out priority 3 qlimit 1
queue web_out priority 4 qlimit 1
queue im_outpriority 5 qlimit 1
queue radio_out priority 6 qlimit 1
queue ssh_out priority 7 qlimit 1
queue dns_out priority 8 qlimit 1
queue udp_gaming_outpriority 11 qlimit 1
queue ip_telefoni_out priority 15
I had a play a while ago with the qlimit but I had it added into the
"altq on rl1.." line, oddly it never changed a thing and never gave
an error. Since seeing your qlimit statements i've been playing with it
for the past couple of days and working on tuning and found a qlimit of
1 serverly limited queues and they never saw full bandwith potential. I
found a good figure for me was 10 as opposed to a standard 50. My
testing of the qlimit number had me pinging a local site while uploading
with Azurues and watching its graph. Basically I tried to get the graph
flat when there was nothing else uploading and it turns sawtoothish when
upload bandwidth is needed. I also tried to get the pings consistant
(icmp traffic is set to 15 for me specifically for testing) and as low
as possible.
Matt.
Re: ALTQ and VoIP
Ingolf Zeiner Petersen wrote:
I've been trying i bit more since I wrote the first mail. I've been
talking in the phone for about an hour now - with full upload (approx 10
torrent seeding from 2 computers i the LAN), and the conversation was
close to perfect, I would say.
The interesting bit now is to see if anybody else get the same experience.
Here is some of my altq config. VoIP traffic has the highest priority,
of course. Any comments are appreciated.
(256Kbit/s ADSL)
altq on rl1 priq bandwidth 170Kb queue { std_out, websrv_out, web_out,
im_out, rdp_out, radio_out, ssh_out, dns_out, udp_gaming_out,
ip_telefoni_out }
queue std_out priq(default red) qlimit 1
queue websrv_outpriority 2 qlimit 1
queue rdp_out priority 3 qlimit 1
queue web_out priority 4 qlimit 1
queue im_outpriority 5 qlimit 1
queue radio_out priority 6 qlimit 1
queue ssh_out priority 7 qlimit 1
queue dns_out priority 8 qlimit 1
queue udp_gaming_outpriority 11 qlimit 1
queue ip_telefoni_out priority 15
(end-section pass-rules)
ip_telefon_fwd = "{ 5060:5061, 16000:1 }"
pass out on rl1 proto udp from any to any port $ip_telefon_fwd keep
state queue ip_telefoni_out
I'm curious -- are you using NAT as well, or do you have enough IP addresses that you
don't need NAT? I've had trouble getting my VOIP to be solid when I'm doing other stuff
(downloading via HTTP) on the same connections. I use a similar configuration to yours.
--
Chris 'Xenon' Hanson | Xenon @ 3D Nature | http://www.3DNature.com/
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and
sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
Re: ALTQ and VoIP
I've been trying i bit more since I wrote the first mail. I've been
talking in the phone for about an hour now - with full upload (approx 10
torrent seeding from 2 computers i the LAN), and the conversation was
close to perfect, I would say.
The interesting bit now is to see if anybody else get the same experience.
Here is some of my altq config. VoIP traffic has the highest priority,
of course. Any comments are appreciated.
(256Kbit/s ADSL)
altq on rl1 priq bandwidth 170Kb queue { std_out, websrv_out, web_out,
im_out, rdp_out, radio_out, ssh_out, dns_out, udp_gaming_out,
ip_telefoni_out }
queue std_out priq(default red) qlimit 1
queue websrv_outpriority 2 qlimit 1
queue rdp_out priority 3 qlimit 1
queue web_out priority 4 qlimit 1
queue im_outpriority 5 qlimit 1
queue radio_out priority 6 qlimit 1
queue ssh_out priority 7 qlimit 1
queue dns_out priority 8 qlimit 1
queue udp_gaming_outpriority 11 qlimit 1
queue ip_telefoni_out priority 15
(end-section pass-rules)
ip_telefon_fwd = "{ 5060:5061, 16000:1 }"
pass out on rl1 proto udp from any to any port $ip_telefon_fwd keep
state queue ip_telefoni_out
Ingolf Zeiner Petersen wrote:
I just got my VoIP adaptor in the mail, and started testing it on my
internet-connection. I want to use BitTorrent and p2p-apps that
maximizes my upstream at the same time as i'm talking in the phone.
I've tried priq and cbq queues now - with good results, but not good
enough. I still get feedback from the people I talk with that i sound a
bit "jagged".
Simple questions: has anybody set up an pf.conf and really tested the
configuration by really maxing the upstream and talking at the same time
(and god feedback from the person in the other end that you sound just
fine - or the person hears echo and other effects).
I've searched on google etc. but I only find people that have config's
that they Believe work - or they aren't using they'r connection hard
enough.
By the way, i'm using Telio (.no)
Thanks in advance!
Re: ALTQ on PF for gaming
[EMAIL PROTECTED] wrote:
> Bob, I have a question about your post. I am already queueing the
> outgoing packets via:
> pass out on $ext_if inet proto { udp tcp } from ($ext_if) to any port
> {27000:27020 } keep state queue(cs_out)
> and it works fine. I am then able to throttle the regular outgoing
> bandwidth way back and still allow some for counterstrike through the
> separate queue. Could you please explain a little on how your solution
> improves on this? I already have a queue for the outgoing cs traffic
> and the way you split it confuses me a little.
I thought the problem was that you needed to limit incoming traffic as
well as outgoing traffic.
You need to have rules for the internal interface too, if you want to
limit the rate at which local machines download incoming packets.
The outgoing (external interface) rule will be very similar to yours,
yes. But you also need the incoming (internal interface) rule to limit
incoming traffic speeds.
--
Bob
Re: ALTQ on PF for gaming
[EMAIL PROTECTED] wrote:
> Hey, I have been looking around everywhere about how to prioritize my
> bandwidth for gaming purposes. So far, I have the outgoing bandwidth
> working fine, but I cannot throttle the incoming bandwidth to optimize
> it for gaming. Whenever I add a rule such as:
> pass in on $ext_if from any to $int_if:network port (gaming ports)
> it seems to not catch any traffic.
You cannot limit download rates over the external interface. You can't
tell your ISP to limit download speed per packet-type, and once it
reaches the router, it's reached the router. Your router can only limit
the rate of packets that *leave* it.
What you have to do is limit the rate at which you feed your local
network, using a rule like this:
pass in on $int_if from $games_machine port >1024 to any port
{ gaming ports/ranges } tag $game_traffic keep state queue(game_in,
ack_in)
This rule will allow games packets in from the local network, tag them
with the $game_traffic tag, keep state so that replies are allowed, and
then add replies to the game_in queue (or ack_in for urgent packet types).
For the external interface, a matching rule should go something like:
pass out on $ext_if proto { udp, tcp } from any to any tagged
$game_traffic modulate state queue(game_out, ack_out)
You might want to split the internal-interface rule so that it allows
different ports for udp and tcp, but it depends on the game.
--
Bob
Re: ALTQ on PF for gaming
Bob, I have a question about your post. I am already queueing the
outgoing packets via:
pass out on $ext_if inet proto { udp tcp } from ($ext_if) to any port
{27000:27020 } keep state queue(cs_out)
and it works fine. I am then able to throttle the regular outgoing
bandwidth way back and still allow some for counterstrike through the
separate queue. Could you please explain a little on how your solution
improves on this? I already have a queue for the outgoing cs traffic
and the way you split it confuses me a little.
Re: ALTQ on PF for gaming
[EMAIL PROTECTED] wrote:
I can add more of the ruleset if needed, but I just want to know how to
prioritize the incoming bandwidth for cs.
I would think that this would work:
pass out on $int_if inet proto { udp tcp } from any { 27000:27020 } to
any port keep state queue (cs_in)
You might want to use a more wide port-range (maybe?).
I'm running the same settings myself for online gaming, but only on the
outgoing traffic. It really sux that I only can have one altq setting
pr. NIC.. (i don't want to shape my internal traffic..)
Hope hearing from you if this was to any help!
RE: altq priq Anomaly?
Amir S Mesry wrote:
> Interesting issue, I have't encountered it. 3MB Down/384KB Up.
>
> altq on $eth0 priq bandwidth 325Kb queue { q_pri, q_def }
> queue q_pri priority 7
> queue q_def priority 1 priq(default
>
> What program are you using to measure it?
Please see my original post... FTP.
RE: altq priq Anomaly?
Stefan Zill wrote: > Jon Hart wrote: > > On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > > > The TCP ACKs are not the issue. The issue is I never get more > > > than half of what I set the bandwidth value to. > > > > I've never been able to get exactly the bandwidth I specified in my > > pf.conf altq rules. > > I almost always get, what I specify in the altq-definitions. Yet, > Once I had such an issue. I ran some kind of local proxy, which > connected from my (tun0) to (tun0) and later this data left through > tun0 on a different connection. The first connection, although not > physically passing through the external interface, consumed > altq-bandwidth. Maybe you have a similiar kind of issue, such that > your traffic passes through altq twice. I removed my problem by > simply using (lo0) to (lo0) connections, instead of (tun0) to (tun0). > Maybe this behaviour can be considered a bug, maybe it can be removed > by using better pf-rules. No proxy is in place, but I might look into this further... or maybe it's a bug.
RE: altq priq Anomaly?
Interesting issue, I have't encountered it. 3MB Down/384KB Up.
altq on $eth0 priq bandwidth 325Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default
What program are you using to measure it?
Amir Mesry
[EMAIL PROTECTED]
Cadillac Jack, Inc.
http://www.cadillacjack.com/
Network & Systems Administrator
2420 Meadowbrook Parkway
Duluth, GA 30096
770-865-0034
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Melameth, Daniel D.
Sent: Thursday, June 23, 2005 7:40 AM
To: pf@benzedrine.cx
Subject: RE: altq priq Anomaly?
Ingolf Zeiner Petersen wrote:
> Melameth, Daniel D. wrote:
> > > I implemented altq's priq a while back in the hope of "speeding
> > > up" my overall 'net connection by prioritizing empty TCP ACKs.
> > > However, I noticed that I was never coming close to my 256Kb/s
> > > upload cap since I did this and looked into it a little bit
> > > further today.
> I don't know if you've got ADSL, but for my own case I got 1024/256
> ADSL, and I have actually set the up-limit to 180Kbit/s to get useful
> latency-rates (together with priq queues). Because empty TCP ACKs is
> much about how fast the packets get sent to the destination - this
> becomes relevant.
>
> Try it, and tell us about your result! :-)
The TCP ACKs are not the issue. The issue is I never get more than half
of what I set the bandwidth value to.
RE: altq priq Anomaly?
Jon Hart wrote: > On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > > The TCP ACKs are not the issue. The issue is I never get more than > > half of what I set the bandwidth value to. > > I've never been able to get exactly the bandwidth I specified in my > pf.conf altq rules. In trying to figure out what bandwidth > specification in pf.conf would give me the rate I pay for, it really > is about 2x. At home I've got 6M down, 768K up. My altq definitions > specify 12M down and 1.5M up and everything works fine. Well, I guess I'm glad I'm not the only one having the issue. I might file a PR.
Re: altq priq Anomaly?
Jon Hart wrote: On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: The TCP ACKs are not the issue. The issue is I never get more than half of what I set the bandwidth value to. I've never been able to get exactly the bandwidth I specified in my pf.conf altq rules. I almost always get, what I specify in the altq-definitions. Yet, Once I had such an issue. I ran some kind of local proxy, which connected from my (tun0) to (tun0) and later this data left through tun0 on a different connection. The first connection, although not physically passing through the external interface, consumed altq-bandwidth. Maybe you have a similiar kind of issue, such that your traffic passes through altq twice. I removed my problem by simply using (lo0) to (lo0) connections, instead of (tun0) to (tun0). Maybe this behaviour can be considered a bug, maybe it can be removed by using better pf-rules. HTH Stefan
Re: altq priq Anomaly?
On Thu, Jun 23, 2005 at 07:39:41AM -0400, Melameth, Daniel D. wrote: > The TCP ACKs are not the issue. The issue is I never get more than half > of what I set the bandwidth value to. I've never been able to get exactly the bandwidth I specified in my pf.conf altq rules. In trying to figure out what bandwidth specification in pf.conf would give me the rate I pay for, it really is about 2x. At home I've got 6M down, 768K up. My altq definitions specify 12M down and 1.5M up and everything works fine. -jon
RE: altq priq Anomaly?
Ingolf Zeiner Petersen wrote: > Melameth, Daniel D. wrote: > > > I implemented altq's priq a while back in the hope of "speeding > > > up" my overall 'net connection by prioritizing empty TCP ACKs. > > > However, I noticed that I was never coming close to my 256Kb/s > > > upload cap since I did this and looked into it a little bit > > > further today. > I don't know if you've got ADSL, but for my own case I got 1024/256 > ADSL, and I have actually set the up-limit to 180Kbit/s to get useful > latency-rates (together with priq queues). Because empty TCP ACKs is > much about how fast the packets get sent to the destination - this > becomes relevant. > > Try it, and tell us about your result! :-) The TCP ACKs are not the issue. The issue is I never get more than half of what I set the bandwidth value to.
Re: altq priq Anomaly?
Melameth, Daniel D. wrote: I implemented altq's priq a while back in the hope of "speeding up" my overall 'net connection by prioritizing empty TCP ACKs. However, I noticed that I was never coming close to my 256Kb/s upload cap since I did this and looked into it a little bit further today. I don't know if you've got ADSL, but for my own case I got 1024/256 ADSL, and I have actually set the up-limit to 180Kbit/s to get useful latency-rates (together with priq queues). Because empty TCP ACKs is much about how fast the packets get sent to the destination - this becomes relevant. Try it, and tell us about your result! :-)
RE: altq priq Anomaly?
I sent this email back in March when I was running 3.5 and didn't look
into this further because this was an older release--but now I'm running
3.7 and I have the same issue. Any ideas? No one on misc@ seems to...
Melameth, Daniel D. wrote:
> I sent something similar to this to misc@ with nary a response so I
> hope someone on this specialized list can shed some light on this...
>
>
> I implemented altq's priq a while back in the hope of "speeding up" my
> overall 'net connection by prioritizing empty TCP ACKs. However, I
> noticed that I was never coming close to my 256Kb/s upload cap since I
> did this and looked into it a little bit further today.
>
>
> It appears an expected bandwidth value for altq in this scenario:
>
> altq on $ext_if priq bandwidth 240Kb queue { tcp_ack, default }
>
> ..limits my upload speed to about half (128Kb/s) of what I should get
> and doubling this value:
>
> altq on $ext_if priq bandwidth 480Kb queue { tcp_ack, default }
>
> ..gives me my 256Kb/s back.
>
> Details below... Any thoughts appreciated.
>
>
> $ uname -mrsv
> OpenBSD 3.5 GENERIC#34 i386
>
> Snippet from my normal pf.conf:
>
> altq on $ext_if priq bandwidth 240Kb queue { tcp_ack, default }
> queue tcp_ack priority 7
> queue default priority 1 priq ( default )
> ..
> nat on $ext_if from $int_if:network to ! $modem -> ( $ext_if:0 )
> nat on $ext_if from $int_if:network to $modem -> $ext_alias
> ..
> pass in quick on $ext_if inet proto tcp from ! $int_if:network to
> \ ( $ext_if:0 ) port ssh flags S/SA keep state queue (
> default,
> tcp_ack )
> ..
> pass out quick on $ext_if inet proto tcp to any flags S/SA \
> keep state queue ( default, tcp_ack )
>
> Output of pfctl -vvs queue during a large FTP upload:
>
> $ sudo pfctl -vvs queue
> queue tcp_ack priority 7
> [ pkts: 5 bytes:270 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> queue default priq( default )
> [ pkts:862 bytes: 754536 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 9/ 50 ]
>
> queue tcp_ack priority 7
> [ pkts: 5 bytes:270 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.0 packets/s, 0 b/s ]
> queue default priq( default )
> [ pkts:952 bytes: 827452 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 11/ 50 ]
> [ measured:18.0 packets/s, 116.67Kb/s ]
>
> queue tcp_ack priority 7
> [ pkts: 8 bytes:432 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.3 packets/s, 129.60 b/s ]
> queue default priq( default )
> [ pkts: 1052 bytes: 907197 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 10/ 50 ]
> [ measured:19.0 packets/s, 122.13Kb/s ]
>
>
> Simply updating my pf.conf with:
>
> altq on $ext_if priq bandwidth 480Kb queue { tcp_ack, default }
>
> ..and reloading my rules with:
>
> $ sudo pfctl -f /etc/pf.conf
>
> ..during the current same FTP upload process gives:
>
> $ sudo pfctl -vvs queue
> queue tcp_ack priority 7
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> queue default priq( default )
> [ pkts: 53 bytes: 54598 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 7/ 50 ]
>
> queue tcp_ack priority 7
> [ pkts: 0 bytes: 0 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.0 packets/s, 0 b/s ]
> queue default priq( default )
> [ pkts:233 bytes: 212130 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 5/ 50 ]
> [ measured:36.0 packets/s, 252.05Kb/s ]
>
> queue tcp_ack priority 7
> [ pkts: 3 bytes:162 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 ]
> [ measured: 0.3 packets/s, 129.60 b/s ]
> queue default priq( default )
> [ pkts:410 bytes: 369754 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 2/ 50 ]
> [ measured:35.7 packets/s, 252.12Kb/s ]
>
>
> So what's going on? Why is the first altq statement not allowing me
> to get close to my maximum (when there is mostly nothing in the higher
> priority queue)?
Re: ALTQ question
Russell Sutherland wrote: > 3. All src IPs in the queue share >the bandwith equally. That is each machine gets >a maximum allocation of N/n Mbps. E.g. If there are 10 src > IP >addresses sending traffic each one gets a maximum >bandwidth of: N/10 Mbps > > Can this be done using ALTQ? I believe its possible using dummynet. It is possible in dummynet using masking. But, as far as I know, ALTQ does not yet offer a way of saying "equal share to each host in this range". You can do it manually, by adding queuing rules for each IP, but even with only three IPs I find that pretty ugly. -- Bob
Re: ALTQ last match queuing?
On Wed, May 25, 2005 at 05:18:18PM -0500, Bill Marquette wrote: > Any thoughts? I haven't looked at code, so I'm not sure how the queue > persists (or doesn't) with a packet. Thanks Queue assignment doesn't work in this way (unlike tags). Only the last matching rule's queue option is relevant. If other rules match earlier, their queue options are not relevant. If the last matching rule doesn't have a queue options (but previously matching rules did), the packet is assigned to the default queue. Daniel
Re: ALTQ: amount of queue rules
--- Matt Pearce <[EMAIL PROTECTED]> wrote: > Hi All, > > I'm about to start working on a few rules for QoS on > inbound TCP and was > wondering if someone could tell me if there is a > maximum of 15 queue's > total or whether I can have 15 rules per in and out > and/or 15 rules per > interface ?? I have had a look around all the > documentation and cant > seem to find a definitive answer so you help before > I go to much further > would be appreciated. > > Thanks, > > Matt. > maximum number of queues are in include files.For CBQ limit is 256, HFSC 64 per interface. Also you can use QoS only on outgoing interface. Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie) Key fingerprint=2499 DE87 82ED 23A8 FD20 3078 04FE 610E 300D 6655 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ALTQ help
On 4/20/05, Steven Bowers <[EMAIL PROTECTED]> wrote:
> This is my first time trying to setup some rules for queueing and I
> could use some assistance. I've gone through the PF FAQ and I think I
> have a bit of a grasp on it, but I'm not quite there yet. The relevant
> portions of my config are shown below. The goals I'm trying to
> accomplish with ALTQ are this:
>
> 1. VoIP traffic takes priority over wire_if and wlan_if traffic.
> 2. Traffic on wire_if takes priority over wlan_if
> 3. wlan_if can borrow or use more bandwidth, only if it is available.
>
> I have setup a second nic and attached it to an AP. It is acting as a
> wireless hot-spot here in my apartment complex. However I use VoIP to
> communicate to the office and need traffic originating from my wired
> LAN to be prioritized over any bandwidth my neighbors are using at the
> same time. If posible I'd like to incorporate Daniel Hartmeier's ACK
> prioritization scheme into the rules.
>
> ## Interfaces##
> ext_if = "fxp0"
> wire_if = "fxp1"
> wlan_if = "fxp2"
>
> external_addr = "x.x.x.x"
> wire_network= "192.168.1.0/24"
> wire_gw = "192.168.1.1/32"
> wlan_network= "192.168.2.0/24"
> wlan_gw = "192.168.2.1/32"
>
> voip_tcp = "5060"
> voip_udp = "{ 5060, 4569, 5036, >< 20001, 2727 }"
> wlan_svcs = "{ domain, pop3, ssh, www, https }"
>
> ## Queueing Rules #
> altq on fxp0 priq bandwidth 800Kb queue { std_out, voip_out, lan_out,
> tcp_ack_out }
>
> # queue definitions
> # std_out - standard queue for all but below
> # voip_out- VoIP traffic (primarily from LAN)
> # lan_out - personal LAN traffic
> # tcp_ack_out - TCP ACK packets with no data payload
>
> queue std_out priq(default)
> queue voip_outpriority 4
> queue lan_out priority 5 priq(red)
> queue tcp_ack_out priority 6
>
read pf.conf(5) again.
try:
altq on fxp0 priq bandwidth 800Kb queue { tcp_ack_out, voip_out,
lan_out, std_out }
queue tcp_ack_out priority 7
queue voip_out priority 5
queue lan_out priority 2 priq(red)
queue std_out priq(default)
In this definition, any packet will be in std_out queue by default,
any packet in lan_out queue will have a higher priority then std_out,
any packet in voip_out queue will have a higher priority then lan_out,
any packet in tcp_ack_out queue will have a higher priority then
voip_out.
All you need to do is type out the correct pass rules.
something like:
pass out on $ext_if ... queue ( std_out, tcp_ack_out )
> altq on fxp1 cbq bandwidth 1.2Mb queue { std_in, int_voip }
> queue std_in bandwidth 1.2Mb cbq(default)
> queue voip_in bandwidth 256Kb cbq(borrow ecn)
>
> altq on fxp2 cbq bandwidth 1.2Mb queue { std_in }
> queue wlan_in bandwidth 256Kb cbq
>
Regards
--
Kimi
Re: altq fishiness
On Thu, Feb 10, 2005 at 07:59:31PM +, Bob wrote: > > I couldn't get CBQ to use up all of the bandwidth. Even when only one > queue had any traffic, the bandwidth was never getting saturated. <...> > Possibly (probably) it was something I was doing wrong. But I've changed > to HFSC now, and my broadband line is saturated with traffic. So I'm happy. remove 'red' and see if it saturates the bandwidth of the queue. red is something i liked the sound of, but stopped using because i think i didn't understand fully its implications on a bandwidth-queue. afaict, if red is on a cbq(/hfsc?) queue which is designed as a bandwidth partition, the bandwidth consumed by the queue will never reach the cap, but will be reduced with some calculus asymptote lines or something as it approaches it. could be way wrong too - i'm going on my interpretation of the effect it had on queues as i watched/tested them. > I have to admit, though, that I couldn't find any simple explanation of > HFSC with regard to PF, so I had to guess my way through setting it up. hfsc has a very steep learning curve, but i believe that is partially its nature. for me it seems it demands you get your head around it, rather than trying to be a bit easier to understand and missing a bit of the picture. the crossbow site is excellent for this, but seems to take several reads through to sink in fully. jared -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: altq fishiness
Jason Murray wrote: > As I understand it the two child ssh queues should just use up all the > bandwidth from the parent. I couldn't get CBQ to use up all of the bandwidth. Even when only one queue had any traffic, the bandwidth was never getting saturated. Possibly (probably) it was something I was doing wrong. But I've changed to HFSC now, and my broadband line is saturated with traffic. So I'm happy. I have to admit, though, that I couldn't find any simple explanation of HFSC with regard to PF, so I had to guess my way through setting it up. -- Bob
Re: altq fishiness
Jason Murray wrote:
Here is the section from pf.conf
Include start
altq on $red cbq bandwidth 3Mb queue { default, web, mail, ssh,
empty_ack }
queue web bandwidth 50% priority 7 cbq(red, borrow)
queue mail bandwidth 15% priority 0 cbq(red, borrow)
queue ssh bandwidth 25% cbq(borrow) { ssh_interactive, ssh_bulk }
queue ssh_interactive priority 7
queue ssh_bulk priority 0
queue empty_ack bandwidth 5% priority 7 cbq(borrow)
queue default bandwidth 5% cbq(default, red, borrow)
Include end
It's based heavily on the example from pf.conf(5). But when I parse
the rules with pfctl -nf /etc/pf.conf I am told:
# pfctl -nf /etc/pf.conf
pfctl: the sum of the child bandwidth higher than parent "ssh"
It's because you haven't give any bandwidth for the ssh_interactive and
ssh_bulk. If you dont, the first child queue get 100%, leaving nothing
for the other. This was added in 3.6 somewhere - gave me som troubles too.
Btw. try searching the archives another time, it has been discused before.
---
Mvh.
IT Ansvarlig
Kim Esben Jørgensen
OE Kabeltv IT A/S
Galnet A/S
Re: altq and rate limiting (packets/sec)
On Wed, Jan 26, 2005 at 09:48:06AM -0500, [EMAIL PROTECTED] wrote: > On Tue, 25 Jan 2005, Christopher Linn wrote: > > >i am interested 9in using altq to limit the outflow from an rfc1918 > >NAT'd network to alleviate the possibility of e.g. DDoS attacks > >originating from within the NAT. > > > >one of our security guys (who is not familiar with pf) mentioned to > >me that i should look for something to rate-limit (packets/sec) > >outgoing, since for example a DDoS SYN flood pointed at a webserver > >port 80/443 just spews little packets at a high rate. but the > >closest thing i see to this is the "qlimit" parameter for max > >packets queued.. doesn't really seem like it would be the same thing. > > > >am i missing something? has this issue been discussed? > > > >i suspect i am missing something.. > > > >cheers, > > > >chris linn > > > > ASAIK pf rate-limits based on bits per second, not packets per second. > qlimit controls depth of queues, not how fast they are emptied. > > You could have two queues, one for syn packets and one for other traffic. > The syn packet queue can be rate limited to X bits/second which can be > based on known small syn packet size. > > Mike as i read this i said to myself, D'OH! we're _queueing_ here!.. ;*) daniel also gave me this advice, which seems like it might even be more apropriate: "... but i wouldn't limit that with altq at all, use max-src-state or similar to limit the number of concurrent _states_ a client can create which limits syn floods (any connection flood, actually) nicely. if you limit a client to 100 concurrent connections, he can start nmap or his favorite syn flood tool, but pf will only create the first 100 states, passing 100 syns, then block until old connections are closed/time out." also to clarify myself, i wasn't specifically worried about SYN flood, but rather any possible flooding that anyone might think up, therefor i was thinking in terms of a more general solution. seems like the use of max-src-state (see pf.conf(5) under STATEFUL TRACKING OPTIONS) fits this nicely. thnaks daniel ;*> cheers, chris -- Christopher Linn, (celinn at mtu.edu) | By no means shall either the CEC Staff System Administrator| or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein.
Re: altq and rate limiting (packets/sec)
ASAIK pf rate-limits based on bits per second, not packets per second. qlimit controls depth of queues, not how fast they are emptied. You could have two queues, one for syn packets and one for other traffic. The syn packet queue can be rate limited to X bits/second which can be based on known small syn packet size. Mike On Tue, 25 Jan 2005, Christopher Linn wrote: i am interested 9in using altq to limit the outflow from an rfc1918 NAT'd network to alleviate the possibility of e.g. DDoS attacks originating from within the NAT. one of our security guys (who is not familiar with pf) mentioned to me that i should look for something to rate-limit (packets/sec) outgoing, since for example a DDoS SYN flood pointed at a webserver port 80/443 just spews little packets at a high rate. but the closest thing i see to this is the "qlimit" parameter for max packets queued.. doesn't really seem like it would be the same thing. am i missing something? has this issue been discussed? i suspect i am missing something.. cheers, chris linn -- Christopher Linn, (celinn at mtu.edu) | By no means shall either the CEC Staff System Administrator| or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein.
Re: altq question
It wasnt very clear to me that i had to apply the queues for INcoming
connections... and right now yes, this really makes the difference.
On Thu, 18 Nov 2004 22:26:06 +0200, colin <[EMAIL PROTECTED]> wrote:
> First of all I want to say Hi to everybody because this is my first thread.
>
> Im rather new to altq and pf but basically i want to limit the http
> traffic from one of my LANs machines.
> Ive tried all the schedulers but i havent noticed any differences between
> them.
>
> Here is a sample of what ive done using cbq:
>
> altq on $EXT_IF cbq bandwidth 256Kb queue {http, other}
>
> queue http bandwidth 6Kb priority 0 cbq (red)
> queue std bandwidth 90% cbq(default)
>
> pass out on $EXT_IF proto tcp from $LAN_IP to any port = 80 \
>flags S/SA modulate state queue http
>
> After ive applied these rules from LAN_IP i was able to browse web
> pages even with 10.24 Kb/s
>
> pfctl -vvsq
>
> [ measured:4.4 packets/s, 9.48Kb/s ]
> [ measured:4.3 packets/s, 10.24Kb/s ]
>
> If this in not correct please tell me what do i miss and what should i
> do to limit that http traffic?
>
> ps Im using OpenBSD 3.6
>
Re: altq on what interface on a bridged setup
> At 11.55 08/11/2004, you wrote: > > > [router]-->[ext_if]-->[inf_if]-->[LAN] > > > bridge > > > > > > Should I only apply queueing on the ext_if? > > > >The problem is when datas are knocking at the door of a NIC, they're > >already here, and it's too late to preserve bandwidth. > > > >So, it's better to use queueing on internal interface of your bridge for > >ingoing datas (which are going to the LAN), even if your lan is certainly > >faster than a Web connection. > > Hi all, > > if I have to shape ingoing AND outgoing datas on a trasparent bridge, > is it ok to apply queueing to both interfaces, ignoring > the FAQ raccomandation? How that said Alexandre - when you have incoming data in your router that is to late to queuing that trafic. But using altq with ecn for that trafic you could slow down incoming stream , and in result you have good shaping for bigger streams (eg. transfer from ftp server, downloading sth. from www) and worser for small packets like ICMP-Ping >From OpenBSD FAQ (about ECN) : "Explicit Congestion Notification (ECN) works in conjunction with RED to notify two hosts communicating over the network of any congestion along the communication path. It does this by enabling RED to set a flag in the packet header instead of dropping the packet. Assuming the sending host has support for ECN, it can then read this flag and throttle back its network traffic accordingly. " Maybe somebody know how ECN work exactly? Darek
Re: altq on what interface on a bridged setup
Kenneth Oncinian wrote:
So does this mean that I need to define and use 2 queues?
Yes, that's what I do. One queue for outbound and another for inbound
although I seem to recall someone (Henning?) saying that you
could give the queues the same name thus making them at least look
like only one queue.
ex:B
altq on $ext_if priq bandwidth 768Kb queue { http0, default }
queue http0 priority 10
queue default priq(default)
altq on $int_if priq bandwidth 768Kb queue { http1, default }
queue http1 priority 10
queue default priq(default)
pass out quick on $ext_if proto tcp from any to any port 8080 queue http0
pass out quick on $int_if proto tcp from any port 8080 to any queue http1
Yes, this looks fine to me except i would use $int_if:network instead of
'any' where applicable and use keep state, ie:
pass out ... from $int_if:network to any port 8080 queue http0 keep state
pass out ... from any port 8080 to $int_if:network queue http1 keep state
---
Lars Hansson
Re: altq on what interface on a bridged setup
Hi Lars,
Thank you for the response,
No, you apply queueing to both BUT you can only
queue outgoing traffic *on that interface*.
So on ext_if you'd queue outbound traffic and
on int_if you'd queue inbound traffic.
Note that you cant really queue traffic that is
being sent *to you* directly since by the time
the packet get to your machine it's already
gone over the wire. All queueing that applies
to inbound traffic is indirect.
So does this mean that I need to define and use 2 queues? One for
$ext_if and one for $int_if and apply queueing to the outgoing traffic
on that interface? or use 1 queue and define both outgoing data on
both interface to that queue?
ex: A
altq on $ext_if priq bandwidth 768Kb queue { http, default }
queue http priority 10
queue default priq(default)
pass out quick on $ext_if proto tcp from any to any port 8080 queue http
pass out quick on $int_if proto tcp from any port 8080 to any queue http
or
ex:B
altq on $ext_if priq bandwidth 768Kb queue { http0, default }
queue http0 priority 10
queue default priq(default)
altq on $int_if priq bandwidth 768Kb queue { http1, default }
queue http1 priority 10
queue default priq(default)
pass out quick on $ext_if proto tcp from any to any port 8080 queue http0
pass out quick on $int_if proto tcp from any port 8080 to any queue http1
?
regards,
Kenneth
Re: altq on what interface on a bridged setup
Kenneth Oncinian wrote: I read that you should only queue on your outgoing interface. Does this rule also apply on a bridged setup? So in my setup: [router]-->[ext_if]-->[inf_if]-->[LAN] bridge Should I only apply queueing on the ext_if? No, you apply queueing to both BUT you can only queue outgoing traffic *on that interface*. So on ext_if you'd queue outbound traffic and on int_if you'd queue inbound traffic. Note that you cant really queue traffic that is being sent *to you* directly since by the time the packet get to your machine it's already gone over the wire. All queueing that applies to inbound traffic is indirect. --- Lars Hansson
Re: altq on what interface on a bridged setup
At 11.55 08/11/2004, you wrote: > [router]-->[ext_if]-->[inf_if]-->[LAN] > bridge > > Should I only apply queueing on the ext_if? The problem is when datas are knocking at the door of a NIC, they're already here, and it's too late to preserve bandwidth. So, it's better to use queueing on internal interface of your bridge for ingoing datas (which are going to the LAN), even if your lan is certainly faster than a Web connection. Hi all, if I have to shape ingoing AND outgoing datas on a trasparent bridge, is it ok to apply queueing to both interfaces, ignoring the FAQ raccomandation? Regards Fabrizio -- Alexandre Anriot [EMAIL PROTECTED]
Re: altq on what interface on a bridged setup
> [router]-->[ext_if]-->[inf_if]-->[LAN] > bridge > > Should I only apply queueing on the ext_if? The problem is when datas are knocking at the door of a NIC, they're already here, and it's too late to preserve bandwidth. So, it's better to use queueing on internal interface of your bridge for ingoing datas (which are going to the LAN), even if your lan is certainly faster than a Web connection. -- Alexandre Anriot [EMAIL PROTECTED]
Re: altq + cbq
On Tue, Oct 26, 2004 at 03:47:27PM -0600, notrox wrote:
> I am running OpenBSD 3.5 and I am trying to do bandwidth limiting to a
> single IP.
> For some odd reason altq isnt borrowing from the root queue.
>
> -
> #pf.conf
>
> ext_if = "tun0"
> int_if = "dc0"
> lan = "192.168.1.0/24"
>
> scrub in all
>
>
> altq on $ext_if cbq bandwidth 400Kb queue {web, bt }
> queue web bandwidth 300Kb cbq(default)
> queue bt bandwidth 100Kb cbq(borrow)
it has been some time since i used cbq - so forgive me if this
is a wrong suggestion - but have you tried also setting cbq
in the 'altq on' to be 'cbq(borrow)' ?
i remember having difficulty getting queues to borrow from their
parent and iirc, i fixed it by also setting borrow on the parent
queue of the childqueue which i wanted to be doing the borrowing.
i just tried 'echo "altq on lo0 cbq(borrow) bandwidth 100Kb queue {fir sec}" | \
pfctl -nvf-'
and it did not complain about the syntax of my altq line.
jared
--
[ openbsd 3.6 GENERIC ( oct 12 ) // i386 ]
Re: Altq + CBQ + borrow
There is some trivial trick ?
> Hello.
> I try run Altq + CBQ with borrow for some queues, but I have some strange
> results . For example:
>
> altq on $int_if cbq (ecn) bandwidth 100Mb queue { lan_q, def_q }
>
> queue def_q bandwidth 95% cbq(default)
> queue lan_q bandwidth 1Mb cbq { ip2_q, ip3_q, . }
>
> queue ip2_q bandwidth 10% cbq(ecn borrow)
> .
> .
>
> In this configuration we should have: ip2_q have at least 10% of 1Mb, but
if
> lan_q is empty ip2_q could borrow some bandwith (max. to 1Mb).
> But i observe, that ip2_q borrow only 100Kb, so ip2_q coul have max.
200Kb.
> Is that some error in my configuration ?
>
> from `pfctl -sq -vv` i have:
>
> queue ip2_q bandwidth 100Kb cbq( red ecn borrow )
> [ pkts: 2277 bytes:3417866 dropped pkts: 0 bytes:
> 0 ]
> [ qlength: 0/ 50 borrows: 1856 suspends: 49 ]
> [ measured:11.4 packets/s, 137.70Kb/s ]
>
>
Re: altq + NAT'd udp packets
On Thu, Jan 29, 2004 at 07:30:09PM -0800, Andre LaBranche wrote:
>
> For some reason, all traffic to and from NAT'd machines falls into the
> default inbound / outbound queues.
do you mean the default with respect to cbq( default ), or the default
with respect to the queue you're deciding you want the packets to go
out of if they're not in a special queue ( as i guess those might not
_need_ to be the same thing ... ) ?
> #pass out quick on sis0 from $local_nets to $local_nets \
> # label local_out queue local_out keep state
> pass out quick on sis0 proto udp from any to any \
> label udp_out queue udp_out
> pass out quick on sis0 inet proto icmp from any to any \
> label icmp_out queue icmp_out keep state
> pass out quick on sis0 proto { tcp udp } from any port domain to any \
> label dns_out queue dns_out keep state
> pass out quick on sis0 proto { tcp udp } from any port $ssh_ports to
> any \
> label ssh_out queue ssh_im_out keep state
i'm guessing that the packets aren't making it into the 'dns_out'
queue because of the pass out _quick_ on the first one up there.
"proto udp from any to any" would indeed match DNS traffic at that
point, so the dns packet would never make it down to the subsequent
rules.
maybe removing quick on the 'catch-all' rules would help?
jared
--
[ openbsd 3.4 GENERIC ( jan 31 ) // i386 ]
Re: altq + NAT'd udp packets
On Thursday, Jan 29, 2004, at 19:30 US/Pacific, Andre LaBranche wrote: I am seeing some odd behavior and I'm not sure what the cause is. I'm using altq / pf in obsd 3.4 to do transparent traffic shaping between my LAN and dsl connection. I'm also using the openbsd machine to do NAT for the few workstations that don't have public IPs. For some reason, all traffic to and from NAT'd machines falls into the default inbound / outbound queues. Most of the rules use "any" as the source and destination, since my goal is to do shaping for various services equally through my network... so I don't see what difference it would make if the host in question has a private or public IP. Does it matter which interface I do NAT on? Currently I'm doing it on the internal one... I'm not really sure what to try next. Any ideas? I don't have any specific comments on the ruleset, but you can add log to the rules and tcpdump -eni pflog0 to see which rules are matching. Use pfctl -vvsr to get the rule numbers.
Re: ALTQ & filter rules
On Mon, Dec 29, 2003 at 05:44:33PM +0700, Ilya A. Kovalenko wrote: > Why queueing filters & packet filters cannot > be configured separatelly ? because that is our design.
Re: ALTQ & filter rules
AES>> 3.4's (and above) "tagging" is your friend :) AES>> if you need skeleton ruleset, this one... > > [skipped] > > hmm ... thanks for method (shaping on lo0, tagging), 'll see > how it works. But the question was "shaping on lo0" is NOT the method :) it is just example to you, ready to pfctl -nf. you need to replace lo0 with interface name where you actually need to shape. but "tagging" is the real and powerful method. > Why queueing filters & packet filters cannot > be configured separatelly ? please, do not waking up Henning :) this question is previuosly answered. see my post "ALTQ: before and after merge" in archives. you just have not catched the main pf+altq idea yet. like i have not previuosly :)
Re: ALTQ & filter rules
Good time of day,
AES> 3.4's (and above) "tagging" is your friend :)
AES> if you need skeleton ruleset, this one...
[skipped]
hmm ... thanks for method (shaping on lo0, tagging), 'll see
how it works. But the question was
Why queueing filters & packet filters cannot
be configured separatelly ?
Shaping & filtering, theoretically, can have completely
different policy.
I.e. not "pass-n-shape" as on your ruleset, but "pass" &
"shape" in different rules/rulesets.
It is development question.
Before 3.3 ALTQ ruleset was completely separated, but inflexible. On
3.3+ ALTQ was merged into PF and pf.conf it become more more flexible
(BIG thanks to developers), but queue filters become hard-linked to
packet filter ruleset.
I think, there is a reasons to let queueing filters to can be
independed from packet filter rules, if need.
Maybe, it means hard work for developers, maybe it is inpossible
at all ('cause, for example, hard deep-low-level dependings), I don't,
really, know. It's just an opinion and feeling, that separated options
must to can be configured separatelly.
Regards,
Ilya A. Kovalenko(mailto:[EMAIL PROTECTED])
S.A.
JSC Oganer-Service
Special Equipment Software section
Re: ALTQ/PF throttling?
On Fri, Nov 21, 2003 at 11:26:32PM -, Dom De Vitto wrote: > Anyone know what the max number of rules is, and how to change it? there's no hard limit - other than RAM. > Obviously stuff like available RAM may be critical, but from the FAQ > I'll know when I hit that limit when I get a panic :-) no. in pf, yes, if you exhaust pool memory, but not in pfctl which is just a userland app like many others. > I read yesterday that only 1024 queues are available - and can check > the change to bang this up, however I'm lost where the rule limit is. no, less, and scheduler dependent. too lazy right now to dog 'em out ;-) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: ALTQ/PF throttling?
(thanks so far all btw) Following on, after some playing around I can create 20,000 rules (!!!) but pfctl just hangs with 30,000 or more Anyone know what the max number of rules is, and how to change it? Obviously stuff like available RAM may be critical, but from the FAQ I'll know when I hit that limit when I get a panic :-) I read yesterday that only 1024 queues are available - and can check the change to bang this up, however I'm lost where the rule limit is. FYI, I want to cut up the entire net into (as small as possible) chunks with individual connection limits and bandwidth restrictions. Thanks in advance, Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jedi/Sector One Sent: Wednesday, November 19, 2003 5:58 PM To: Dom De Vitto Cc: [EMAIL PROTECTED] Subject: Re: ALTQ/PF throttling? On Tue, Nov 18, 2003 at 10:22:43PM -, Dom De Vitto wrote: > Does anyone know/have a way to throttle (delay or drop) on: > b) Limit the number of connections from a single host. > b) Bandwidth of 'any' individual client being greater than some value. Unfortunately I don't think PF is able to handle per-client rules yet. Or you have to create as many rules as possible client IP address (!). -- __ /*- Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\ __ \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' / \/ http://www.Jedi.Claranet.Fr/";> Misc. free software \/
Re: ALTQ/PF throttling?
On Tue, Nov 18, 2003 at 10:22:43PM -, Dom De Vitto wrote: > Does anyone know/have a way to throttle (delay or drop) on: > b) Limit the number of connections from a single host. > b) Bandwidth of 'any' individual client being greater than some value. Unfortunately I don't think PF is able to handle per-client rules yet. Or you have to create as many rules as possible client IP address (!). -- __ /*- Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\ __ \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' / \/ http://www.Jedi.Claranet.Fr/";> Misc. free software \/
Re: ALTQ/PF throttling?
Hi, Quoting Dom De Vitto <[EMAIL PROTECTED]>: > Does anyone know/have a way to throttle (delay or drop) on: > > a) Number of active connections matching a particular rule. > b) Limit the number of connections from a single host. > b) Bandwidth of 'any' individual client being greater than some value. For a), from 'man pf.conf' : All three of keep state, modulate state and synproxy state support the following options: max _number_ Limits the number of concurrent states the rule may create. When this limit is reached, further packets matching the rule that would create state are dropped, until existing states time out. Example : pass in proto tcp all port www flags S/SA keep state max 100 A++ Foxy -- Laurent Cheylus <[EMAIL PROTECTED]> OpenPGP ID 0x5B766EC2
Re: ALTQ: Queueing incoming Traffic ;-) ?! -- Problems with Proxy Services
silly me, now the ascii doodles should look ok. sorry Queueing incoming Traffic ?! ALTQ can be used to queue outgoing traffic on a network device. Incoming traffic to a network device CAN NOT be queued.. ..atleast not directly ;) However, when using ALTQ on a Router, e.g. a Firewall between the Internet and your local LAN, one can queue the INCOMING traffic from the internet as OUTGOING traffic to the local LAN ! Get it? Short Example: (internet)<- - - - - - - - - - - - - - - - - - - - - - -> (client) <-- [external_iface]...queue_OUT... [internal_iface] <-- --> [external_iface] ...queue_IN...[internal_iface] --> This seems to work. +++ Problems arise when one runs proxy services on the Firewall. Take this example with Squid: (internet)< - - - - - - - - - - - - - - - - - - - - - - -> (client) <-- [external_iface]..queue_OUT.<-+ +--<[internal_iface]<-- | | [[ Squid on Localhost ]] | | --> [external_iface] -->-+ +->..queue_IN..[internal_iface]--> Situation 1: Squid has WWW Site cached -> queue_IN is not appropiate as the Data the client recieves comes from the Firewall itself and is **NOT** incoming via external iface Situation 2: Squid needs to load WWW Site -> queue_IN (data squid sends to client) does probably match the actual incoming data via external interface that squid did recieve. With a rule on the Firewall for Squid accessing Internet HTTP Servers like this: pass out on $external_if inet tcp from $external_ip to any port 80 \ keep state queue (http_ext_out) queue http_ext_out will catch all OUTGOING to any port 80 traffic (including the tcp ack for incoming) but not incoming traffic -- again: ONLY OUTGOING traffic can be queued. amen. ;) +++ Now, what i did and what seems to work is using a third network device, the Loopback device ! pass out on $external_if inet tcp from $external_ip to any port 80 \ queue (http_ext_out) pass in on $external_if route-to to $localhost_if inet tcp from any\ port 80 to $external_ip queue (http_ext_in) Strange? Well, it works. Queue http_ext_in catches the incoming http traffic. squid doen't care about interfaces (the source and destination ip's are unchanged) and is happy recieving the data. (internet)<- - - -- - - - - - - - - - - - - - - - - - - - -> (client) <-- [external_iface]..queue_OUT.<-+ +--[internal_iface]<-- | | [[ Squid on Localhost ]]-->[internal_iface]--> | [localhost_iface]..queue_IN.. | route-to localhost_iface | --> [external_iface]--->+ +++ And now, my Problem ;) With my route-to localhost Solution i can queue the incoming traffic but i loose the statefull inspection features of pf :( . . If i use Statefull inspection, a state will be created for the incoming http packets, state rules are evaluated before any other rules and the route-to rule *never* sees the packets. Looking forward for you network guru's to comment on that :) Thanks to all contributers to the pf-mailing list. Keep up the good work! Yours Torsten aka erpel23
Re: altq with vlan
ive tried all possible combinations for pass in on vlan1 from to any keep state queue opium_d_l but it does not work i think i will have to do something else.. any idea's? however pass out on fxp0 from to any keep state queue opium_u_l works fine but this is for outgoing traffic thanks Guns don't kill people..., I KILL PEOPLE! On Wed, 30 Jul 2003, Mark Bojara wrote: >Hello Daniel, > >Sorry my mistake, The packets are being tagged. However I do not have any >incoming or outgoing access. This is probably a error with my filters. Do >you have any advice on what i could try? > >Thanks >Mark > > > >(A)bort, (R)etry, (F)orget It! > >On Wed, 30 Jul 2003, Daniel Hartmeier wrote: > >>First, check whether your rules match: >> >> $ pfctl -vsr | grep -A 1 queue >> >>If they do, check whether tagged packets get queued: >> >> $ pfctl -vsq >> >>Daniel >> > >
Re: altq with vlan
Hello Daniel, Sorry my mistake, The packets are being tagged. However I do not have any incoming or outgoing access. This is probably a error with my filters. Do you have any advice on what i could try? Thanks Mark (A)bort, (R)etry, (F)orget It! On Wed, 30 Jul 2003, Daniel Hartmeier wrote: >First, check whether your rules match: > > $ pfctl -vsr | grep -A 1 queue > >If they do, check whether tagged packets get queued: > > $ pfctl -vsq > >Daniel >
Re: altq with vlan
First, check whether your rules match: $ pfctl -vsr | grep -A 1 queue If they do, check whether tagged packets get queued: $ pfctl -vsq Daniel
Re: ALTQ help request
On Friday, Jul 18, 2003, at 21:03 US/Pacific, Mark Fordham wrote: I'm trying to get ALTQ working with the following setup without much success. To test I'm doing a simultaneous FTP upload and download from a Windows box on the internal network. The upload is being limited to 100Kb as expected but the download drops off rapidly after starting the upload. OpenBSD 3.3 snapshot 2003-06-06 ADSL 512/128 using PPPoE A performance/bugfix patch for tun(4) was added Jun 12: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/ if_tun.c.diff?r1=1.47&r2=1.48 Volker's tests and commentary may help: http://secspace.de/altq_on_tun.html Your rules look fine.
Re: altq/pf not working
On Monday, Jul 7, 2003, at 03:58 US/Pacific, Pawel S wrote: I have 512/512 kbit adsl connection to Internet and 100Mbit on internal side of the firewall. I want to prioritize shoutcast/mp3, windows media services, icq messages and udp traffic higher than ftp and http bulk downloads and other tcp traffic. Additionally, I want ssh and tcp ack packets to have highest priority. Kernel is patched with Trevor Talbot's patch. The rules look fine. I basically have 3 levels of priority. I split 100 Mbit on internal interface in to 488 kbits for internet traffic and the rest for internal traffic. I don't want ftp and http traffic to use more then 100 kbits when there is shoutcast or wma traffic present, but do get full 488 otherwise. The problem is that the bulk traffic never gets more then 100kbits when there is no other traffic, despite "borrow" word. You may be running into a limitation of CBQ. Check out section 2.8 in http://www.csl.sony.co.jp/person/kjc/kjc/software/TIPS.txt You can use pfctl -vsq to make sure the class is actually borrowing when it should be. Watching the throughput of a UDP stream might be useful, as it won't self-throttle like TCP will. If this is the case, removing the 100Kb limit and just relying on the priorities may work better. Note that inbound traffic handling is going to behave a little differently than outbound, since the queueing is basically only adding latency. Using cbq(red) or small qlimit values on the low priority queues may be helpful, since they will increase drops. I haven't run any tests myself, so I don't have any hard information to offer.
Re: altq/pf not working
> My pf/altq rules do not seem to work and I can't find any errors. > Here is the background. are you running 3.3 release or current? If you're running release, you probably have to patch the tun0 interface. Look here for some information I've collected: http://secspace.de/altq_on_tun.hmtl -volker
Re: altq vs pppoe
Hi Trevor, > As I don't have a PPPoE setup to work with, I did my own testing with > just > tun0, and saw the spin effect. Below is a patch for if_tun.c, which > fixed > the problem I observed. I'd like to know if it fixes pppoe queueing > for anyone brave enough to try patches from me. it works very well for me, too. I've put together some graphics and a little description on http://secspace.de/altq_on_tun.html As you can see, the results are impressing! Thank you very much -volker
Re: altq vs pppoe
On Tuesday, Jun 10, 2003, at 05:07 US/Pacific, Tobias Wigand wrote: same here, works great with a saturated link. i can upload with full speed and it doesn´t slow down my downloads at all! Great! okay, surfing around while uploading is slower than normal, but thats something we have to live with, right? The outgoing connection setup and page requests have to compete with your uploads. You could experiment with a rule that puts everything out to tcp port 80 in a priority queue. Just don't do any HTTP uploads :)
RE: altq vs pppoe
> Henning Brauer wrote ... > > > > why not just run -current ;-) > > > > Because I also run few mailing lists and intend to minimize > > downtime on that computer. IOW, I am also very very > > conservative :-) > > but for updating to latest stable you need one reboot anyway - so why > not just apply the patch, build kernel, reboot and be happy ;-) Been there, done that. Am happy. Would be even happier when ppp(oe) runs on the kernel-side and I can queue on the phys if. But I can wait. Primoz
Re: altq vs pppoe
On Tue, Jun 10, 2003 at 03:39:36PM +0200, Primo? Gabrijel?i? wrote: > > Henning Brauer wrote ... > > > > > > > After all positive feedback - is there any chance we can > > > > > see this submitted to -stable? I think quite some people > > > > > would applaud to that. > > > > > > > > I intend to get that into -current soonish. > > > > > > > > it's not really a -stable thing - only bugfixes go to -stable. > > > > > > Preventing the if_tun to spin without a reason isn't a bugfix? > > > > not really. that changes how tun interfaces work. > > > > the reason -stable is so stable is that we are very very very > > conservative and careful with what goes to -stable. I don't > > think this is a candidate. > > > > why not just run -current ;-) > > Because I also run few mailing lists and intend to minimize downtime on that > computer. IOW, I am also very very conservative :-) but for updating to latest stable you need one reboot anyway - so why not just apply the patch, build kernel, reboot and be happy ;-) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: altq vs pppoe
> Henning Brauer wrote ... > > > > > After all positive feedback - is there any chance we can > > > > see this submitted to -stable? I think quite some people > > > > would applaud to that. > > > > > > I intend to get that into -current soonish. > > > > > > it's not really a -stable thing - only bugfixes go to -stable. > > > > Preventing the if_tun to spin without a reason isn't a bugfix? > > not really. that changes how tun interfaces work. > > the reason -stable is so stable is that we are very very very > conservative and careful with what goes to -stable. I don't > think this is a candidate. > > why not just run -current ;-) Because I also run few mailing lists and intend to minimize downtime on that computer. IOW, I am also very very conservative :-) Primoz
Re: altq vs pppoe
On Tue, Jun 10, 2003 at 03:07:09PM +0200, Primo? Gabrijel?i? wrote: > > Henning Brauer wrote ... > > > > After all positive feedback - is there any chance we can > > > see this submitted to -stable? I think quite some people > > > would applaud to that. > > > > I intend to get that into -current soonish. > > > > it's not really a -stable thing - only bugfixes go to -stable. > > Preventing the if_tun to spin without a reason isn't a bugfix? not really. that changes how tun interfaces work. the reason -stable is so stable is that we are very very very conservative and careful with what goes to -stable. I don't think this is a candidate. why not just run -current ;-) -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: altq vs pppoe
> Henning Brauer wrote ... > > After all positive feedback - is there any chance we can > > see this submitted to -stable? I think quite some people > > would applaud to that. > > I intend to get that into -current soonish. > > it's not really a -stable thing - only bugfixes go to -stable. Preventing the if_tun to spin without a reason isn't a bugfix? Primoz
Re: altq vs pppoe
On Tue, Jun 10, 2003 at 02:38:45PM +0200, Primo? Gabrijel?i? wrote: > > > Great! Hopefully this will hold for everyone else who's testing it. > > > > same here, works great with a saturated link. i can upload with full speed > > and it doesn´t slow down my downloads at all! > > okay, surfing around while uploading is slower than normal, but thats > > something we have to live with, right? > > After all positive feedback - is there any chance we can see this submitted > to -stable? I think quite some people would applaud to that. I intend to get that into -current soonish. it's not really a -stable thing - only bugfixes go to -stable. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: altq vs pppoe
> > Great! Hopefully this will hold for everyone else who's testing it. > > same here, works great with a saturated link. i can upload with full speed > and it doesn´t slow down my downloads at all! > okay, surfing around while uploading is slower than normal, but thats > something we have to live with, right? After all positive feedback - is there any chance we can see this submitted to -stable? I think quite some people would applaud to that. Best regards, Primoz
Re: altq vs pppoe
On 10/06/2003, Tobias Wigand <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > same here, works great with a saturated link. i can upload with full speed > and it doesn´t slow down my downloads at all! > okay, surfing around while uploading is slower than normal, but thats > something we have to live with, right? altq is neat, but it's not a perpetuum mobile generating more bandwidth then you acutally have :)) it just uses it more intelligently.. ciao -- pb - Philipp Buehler
RE: altq vs pppoe
> > The only weird thing I have noticed is that the download started at > > 127 KB/s (full DL bandwidth of my ADSL link), but then slowly > > dropped to the 60 KB/s and stabilized there. During that slowdown, > > pppoe CPU% raised to the 26% and then stabilised. When download > > completed, pppoe CPU% normalized back to the < 1%. > > Do you know if it does the same thing without queueing enabled? I > realize this would be hard to test with a saturated uplink. I'm > wondering if the CPU usage is in direct response to the queueing, > or just a result of the traffic patterns. All tests done over 1024/256 ADSL link. 1xDL: - ppp 5% - pppoe 2% - DL 100-119 KB/s 1xUL: - ppp 2% - pppoe in range of 0.1% - UL 25-27 KB/s 1xDL + 1xUL - ppp 6-7% - pppoe 5-7% - DL 100-119 KB/s - UL 22-25 KB/s I'd say that it works great and that yesterday's results were caused by some traffic anomaly, possibly outside my control. Primoz
Re: altq vs pppoe
On Monday, Jun 9, 2003, at 02:14 US/Pacific, Primož Gabrijelčič wrote: Trevor Talbot wrote ... As I don't have a PPPoE setup to work with, I did my own testing with just tun0, and saw the spin effect. Below is a patch for if_tun.c, which fixed the problem I observed. I'd like to know if it fixes pppoe queueing for anyone brave enough to try patches from me. I've been known to make things explode. As far as I'm concerned, this patch works just great. I can finally queue on tun0 with my _upload_ bandwidth (minus the pppoe overhead). PPPoE hasn't blown up yet and computer still processes packets correctly. Download works much better over the saturated link now. Great! Hopefully this will hold for everyone else who's testing it. The only weird thing I have noticed is that the download started at 127 KB/s (full DL bandwidth of my ADSL link), but then slowly dropped to the 60 KB/s and stabilized there. During that slowdown, pppoe CPU% raised to the 26% and then stabilised. When download completed, pppoe CPU% normalized back to the < 1%. Do you know if it does the same thing without queueing enabled? I realize this would be hard to test with a saturated uplink. I'm wondering if the CPU usage is in direct response to the queueing, or just a result of the traffic patterns. This could, of course, be the result of the user-landness of OBSD ppp. CPU usage in general, no doubt; but I'm slightly concerned that pppoe's usage went higher as less traffic came through. It's likely that pppoe is contributing to the drop in throughput. Unless TCP just settled down, and the outbound traffic was more frequent -- pppoe would then have to wrap packets at a faster rate, which could account for it. Something I'm unsure of is the interaction between ppp and pppoe. In the tun0 case, ppp's spinning should not make pppoe's CPU usage rise. Choke it, yes; stress it, no. I wonder if ppp is doing something silly itself. I don't think I can go much farther than the if_tun.c stuff myself, as I don't understand the other components (ppp in particular). If there's still a problem with the queueing, I can keep looking, but otherwise this would probably be a discussion to start on one of the other lists.
RE: altq vs pppoe
> Trevor Talbot wrote ... > > I did some playing around and discovered something. It seems that > someone forgot to fully ALTQify tun0. Specifically, select() > always returns read-ready if there's any data in the internal queue, > whether ALTQ's discipline is ready to release it or not. > > The theory is that when the queues start filling, ppp's non-blocking > I/O loop starts spinning on tun0, trying to pull packets off when > they aren't ready. Once it starts spinning, pppoe will be adversely > affected and lose throughput. > > As I don't have a PPPoE setup to work with, I did my own testing with > just tun0, and saw the spin effect. Below is a patch for if_tun.c, > which fixed the problem I observed. I'd like to know if it fixes > pppoe queueing for anyone brave enough to try patches from me. I've > been known to make things explode. As far as I'm concerned, this patch works just great. I can finally queue on tun0 with my _upload_ bandwidth (minus the pppoe overhead). PPPoE hasn't blown up yet and computer still processes packets correctly. Download works much better over the saturated link now. The only weird thing I have noticed is that the download started at 127 KB/s (full DL bandwidth of my ADSL link), but then slowly dropped to the 60 KB/s and stabilized there. During that slowdown, pppoe CPU% raised to the 26% and then stabilised. When download completed, pppoe CPU% normalized back to the < 1%. This could, of course, be the result of the user-landness of OBSD ppp. Now I'll recompile the kernel on the second firewall with faster ADSL (4Mb/768Kb) and test (and report, of course). Best regards and thanks, Primoz
RE: altq vs pppoe
Well if it was an accident at least I know, lol. I will try it also, as I want to see if it works with mine, I am using pppoe as well. I won't blame you if things go haywire, lol. Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trevor Talbot Sent: Saturday, June 07, 2003 8:29 PM To: [EMAIL PROTECTED] Subject: Re: altq vs pppoe On Saturday, Jun 7, 2003, at 14:52 US/Pacific, Amir Seyavash Mesry wrote: > So, let me ask, is the "if_tun.c" file supplied compat with 3.3 and > does it > require the kernel sources only, or the whole source tree? I think sending the attachment to the list was an accident. I sent it to Tobias when he had trouble with the patch at the end of my last email. Both are for 3.3-stable, kernel sources only.
Re: altq vs pppoe
On Saturday, Jun 7, 2003, at 14:52 US/Pacific, Amir Seyavash Mesry wrote: So, let me ask, is the "if_tun.c" file supplied compat with 3.3 and does it require the kernel sources only, or the whole source tree? I think sending the attachment to the list was an accident. I sent it to Tobias when he had trouble with the patch at the end of my last email. Both are for 3.3-stable, kernel sources only.
RE: altq vs pppoe
So, let me ask, is the "if_tun.c" file supplied compat with 3.3 and does it require the kernel sources only, or the whole source tree? Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tobias Wigand Sent: Saturday, June 07, 2003 9:22 AM To: 'Trevor Talbot'; [EMAIL PROTECTED] Subject: AW: altq vs pppoe hi, > I attached a copy of the entire if_tun.c you can drop in instead, > though. it compiles now. and as far as i can see (with some quick testing here, at my parents over the weekend :), queueing on tun0 works at least better than it ever did before. it may need some fine tuning regarding the uplink speed. i´ll be able test more extensive that on monday and let you know. many thanks! tobias
Re: altq-(ipv6 tunnel|multiple ifs) questions
On Friday, May 30, 2003, at 15:26 US/Pacific, b bee wrote: # takes care of traffic going towards outside pass out on $ext_if queue q_on_ext_if keep state that won't work, because $ext_if is being nat'ed. i need to use seperate queues for some of the internal hosts (p2p host, server subnet, wireless clients), and since nat comes before filtering, i would have no way to distinguish between the hosts once the packets hit the filter. Actually, there's a nat feature you might be able to make use of: nat on $ext_if from to any -> $trans_addr port 5:55000 Then filter based on the source port, 4><55001. Unfortunately, this is currently broken for little-endian machines. See my previous post. Yeah, that can be a problem when doing NAT but only if you're classifying traffic based on the source IP address or port. I suppose the alternative is not to keep state on $int_if? pass in on $int_if ... queue q_on_ext_if pass out on $int_if ... queue q_on_int_if i thought you needed to keep state to do queueing? No, state is not required. The packets are tagged as they travel, the state entry just saves the tag.
Re: altq-(ipv6 tunnel|multiple ifs) questions
On Sat, May 31, 2003 at 12:26:28AM +0200, b bee wrote: > > On Fri, 30 May 2003, j knight wrote: > > >b bee wrote: > > > >> the router talks ipv6 to boxen behind three of the interfaces (not > >> $ext_if). my external ipv6 connectivity is via a tunnel over v4 (via > >> $ext_if, obviously). it is fairly simple to classify the traffic of > >> outgoing ipv6 connections (i just make a "pass out on gif0 ... queue > >> (q_on_ext_if)" rule, and it gets put in the right queue as it goes out on > >> $ext_if), but can't think of a way to do this for incoming v6 connections > >> (other than sticking the whole tunnel in the same queue, which would lump > >> all the v6 traffic together and that is not what i want). any hints? > >> i don't suppose pf can look "inside" the tunnel as the packets pass in on > >> $ext_if.. > > > >Why can't you tag packets "in on gif0" into a queue that's been defined > >on one of the internal interfaces? > > because the queue that i'd be tagging for lives on the external interface, > and not the internal ones. i'm trying to partition my external uplink in > this case, not the downlink. i need to put ipv6 connections to servers in > the same queue as the ipv4 connections. > "pass in on gif0 ... queue (q_on_ext_if)" would not work, right? since the > state it creates lives on gif0 and the queue lives on $ext_if, which is > "upstream".. i haven't tried this though, i just thought it wouldn't work. this does work. you _can_ tag on another interface than you are queueing on. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: altq-(ipv6 tunnel|multiple ifs) questions
On Fri, 30 May 2003, j knight wrote: >b bee wrote: > >> the router talks ipv6 to boxen behind three of the interfaces (not >> $ext_if). my external ipv6 connectivity is via a tunnel over v4 (via >> $ext_if, obviously). it is fairly simple to classify the traffic of >> outgoing ipv6 connections (i just make a "pass out on gif0 ... queue >> (q_on_ext_if)" rule, and it gets put in the right queue as it goes out on >> $ext_if), but can't think of a way to do this for incoming v6 connections >> (other than sticking the whole tunnel in the same queue, which would lump >> all the v6 traffic together and that is not what i want). any hints? >> i don't suppose pf can look "inside" the tunnel as the packets pass in on >> $ext_if.. > >Why can't you tag packets "in on gif0" into a queue that's been defined >on one of the internal interfaces? because the queue that i'd be tagging for lives on the external interface, and not the internal ones. i'm trying to partition my external uplink in this case, not the downlink. i need to put ipv6 connections to servers in the same queue as the ipv4 connections. "pass in on gif0 ... queue (q_on_ext_if)" would not work, right? since the state it creates lives on gif0 and the queue lives on $ext_if, which is "upstream".. i haven't tried this though, i just thought it wouldn't work. > >> another altq question. i want to take this setup to the next level and make >> altq partition my downlink as well. is this possible when there is more >> than one "internal" interface? i need to make a queue that transcends the >> interfaces, i.e. to cap bandwidth for a group of connections regardless of >> what interface they live on. > >If I understand correctly, you want to classify say all HTTP traffic >regardless of which internal network the traffic is destined for, right? >You could: decide how much aggregate bandwidth HTTP is to have and then >create a queue on each internal interface giving each one third of that >bandwidth. This bites though because one queue cannot borrow from >another queue on a different interface; each internal network would be >limited to 1/3 the aggregate HTTP bandwidth. The only way I can see is >to queue on the upstream router. exactly, and i don't want it to bite like that :( queueing on an upstream router (i'd have to build one though) would indeed work if i make it (rather than the first router) do the nat (since what i want to do is more complicated than just "give traffic that comes from port 80 priority"). but throwing extra hardware at a perfectly leet setup is ugly. i don't suppose something that'd make the extra router unnecessary is in the works? i don't think trans-interface queues are likely, but i do still have the old altq manpages around, what's this "conditioner" altq.conf(5) talks about? "a queueing discipline ... to meter ... incoming packets". devs? > >> even if this is possible, how will i classify this traffic? some of the >> rules that create the relevant states already have queue keywords for the >> altq on $ext_if... > >You mean you're doing this? > > pass in on $int_if queue q_on_ext_if keep state > pass out on $ext_if keep state > >Do something like this instead: > > # takes care of return traffic from outside > pass in on $int_if queue q_on_int_if keep state > # takes care of traffic going towards outside > pass out on $ext_if queue q_on_ext_if keep state that won't work, because $ext_if is being nat'ed. i need to use seperate queues for some of the internal hosts (p2p host, server subnet, wireless clients), and since nat comes before filtering, i would have no way to distinguish between the hosts once the packets hit the filter. > >> hmm, wouldn't this also be a problem in the case that there is only one >> internal interface? unless you only classify traffic with rules that match >> on the same if that the queue is attached to, which would severely limit >> the usefulness of altq (atleast if you need to do nat, too).. >> now that i think about it, packet tagging might solve that last problem. >> i'll have to unfubar my tree and bump it to -current so i can play with >> tagging.. > >Yeah, that can be a problem when doing NAT but only if you're >classifying traffic based on the source IP address or port. I suppose >the alternative is not to keep state on $int_if? > > pass in on $int_if ... queue q_on_ext_if > pass out on $int_if ... queue q_on_int_if > i thought you needed to keep state to do queueing? btw, "only if"? classifying by source ip or port is pretty much the only way altq is useful/sane if you have anything other than servers around.. ahh, the intricate delights of doing nat.. makes me want to migrate to ipv6-only. assuming i can get the tunnel queueing thing to work.. > > >.joel > anyway. thanks for your reply. b bee
Re: altq-(ipv6 tunnel|multiple ifs) questions
b bee wrote: the router talks ipv6 to boxen behind three of the interfaces (not $ext_if). my external ipv6 connectivity is via a tunnel over v4 (via $ext_if, obviously). it is fairly simple to classify the traffic of outgoing ipv6 connections (i just make a "pass out on gif0 ... queue (q_on_ext_if)" rule, and it gets put in the right queue as it goes out on $ext_if), but can't think of a way to do this for incoming v6 connections (other than sticking the whole tunnel in the same queue, which would lump all the v6 traffic together and that is not what i want). any hints? i don't suppose pf can look "inside" the tunnel as the packets pass in on $ext_if.. Why can't you tag packets "in on gif0" into a queue that's been defined on one of the internal interfaces? another altq question. i want to take this setup to the next level and make altq partition my downlink as well. is this possible when there is more than one "internal" interface? i need to make a queue that transcends the interfaces, i.e. to cap bandwidth for a group of connections regardless of what interface they live on. If I understand correctly, you want to classify say all HTTP traffic regardless of which internal network the traffic is destined for, right? You could: decide how much aggregate bandwidth HTTP is to have and then create a queue on each internal interface giving each one third of that bandwidth. This bites though because one queue cannot borrow from another queue on a different interface; each internal network would be limited to 1/3 the aggregate HTTP bandwidth. The only way I can see is to queue on the upstream router. even if this is possible, how will i classify this traffic? some of the rules that create the relevant states already have queue keywords for the altq on $ext_if... You mean you're doing this? pass in on $int_if queue q_on_ext_if keep state pass out on $ext_if keep state Do something like this instead: # takes care of return traffic from outside pass in on $int_if queue q_on_int_if keep state # takes care of traffic going towards outside pass out on $ext_if queue q_on_ext_if keep state hmm, wouldn't this also be a problem in the case that there is only one internal interface? unless you only classify traffic with rules that match on the same if that the queue is attached to, which would severely limit the usefulness of altq (atleast if you need to do nat, too).. now that i think about it, packet tagging might solve that last problem. i'll have to unfubar my tree and bump it to -current so i can play with tagging.. Yeah, that can be a problem when doing NAT but only if you're classifying traffic based on the source IP address or port. I suppose the alternative is not to keep state on $int_if? pass in on $int_if ... queue q_on_ext_if pass out on $int_if ... queue q_on_int_if .joel
Re: ALTQ / Bandwidth Control Features In OBSD V3.2?
On Sat, Apr 05, 2003 at 02:17:50PM -0500, Tyrcadia Von Nettesheim wrote: > One last question on the subject - would either of you (or anyone who > reads this), have a recommendation as to what type of queueing > strategy would be most useful for this situation: > > Capping the bandwidth maximum for a user going outbound through my > two-NIC firewall to 128kBps, > also realizing the internal and external interfaces are 10mBps > Ethernet? I'm basically trying to rate-limit / queue someone out @ > 128kBps outbound to anywhere on the 'Net. CBQ. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: ALTQ / Bandwidth Control Features In OBSD V3.2?
On Sat, 05 Apr 2003 00:49:56 -0500, Tyrcadia Von Nettesheim <[EMAIL PROTECTED]> wrote: >Many thanks in advance for replies. Thanks to both of you in this thread for responding, and Laurent - thanks for reading what I was trying to ask even though I didn't correctly ask it! One last question on the subject - would either of you (or anyone who reads this), have a recommendation as to what type of queueing strategy would be most useful for this situation: Capping the bandwidth maximum for a user going outbound through my two-NIC firewall to 128kBps, also realizing the internal and external interfaces are 10mBps Ethernet? I'm basically trying to rate-limit / queue someone out @ 128kBps outbound to anywhere on the 'Net. Thanks again for your time! -T
