Re: ALTQ
Stuart Henderson s...@spacehopper.org 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 14:23:48 +0200
Helmut Schneider jumpe...@gmx.de 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
From: Robert rob...@openbsd.pap.st
Helmut Schneider jumpe...@gmx.de 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 15:39:48 +0200
Helmut Schneider jumpe...@gmx.de wrote:
From: Robert rob...@openbsd.pap.st
Helmut Schneider jumpe...@gmx.de 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 rob...@openbsd.pap.st
On Tue, 14 Apr 2009 15:39:48 +0200
Helmut Schneider jumpe...@gmx.de wrote:
From: Robert rob...@openbsd.pap.st
Helmut Schneider jumpe...@gmx.de 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 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
On Tue, 14 Apr 2009 17:37:42 +0200
Helmut Schneider jumpe...@gmx.de wrote:
From: Robert rob...@openbsd.pap.st
On Tue, 14 Apr 2009 15:39:48 +0200
Helmut Schneider jumpe...@gmx.de wrote:
From: Robert rob...@openbsd.pap.st
Helmut Schneider jumpe...@gmx.de 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 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/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 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 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 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 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 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 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, 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
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
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
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
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:
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
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:
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
[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:
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?
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 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?
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?
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?
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?
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?
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?
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?
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 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: 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 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 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
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
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:
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)
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 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 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
[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 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
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
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:
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 + 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 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
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/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] -*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/
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 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 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 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.47r2=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
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 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
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 doesnt 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 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
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? 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
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 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
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
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 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-(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-(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
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 wireless to any - $trans_addr port 5:55000 Then filter based on the source port, 455001. 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 / Bandwidth Control Features In OBSD V3.2?
On Sat, Apr 05, 2003 at 12:49:56AM -0500, Tyrcadia Von Nettesheim wrote: Are the ALTQ / bandwidth control features available in the stock flavor of PF distributed with the stock V3.2 release version, unpatched from the CD sources / binaries? no, it's new for 3.3. If so, could you point me to a good resource I go educate myself at? pf.conf(5) -- 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 simple inside/outside configuration 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
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 simple inside/outside configuration 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 ack prioritization
On Thu, Mar 06, 2003 at 09:09:14PM -0500, Jason Dixon wrote: I forgot to mention, I'm running -snapshot from 3/2/03. It doesn't look like what happened to me was caused by any bugs (that Henning has mentioned in the meantime), but I'm curious... were any of those bugs fixed after my snapshot? I keep forgetting WHEN I fixed stuff ;-) ok, cvs log helps. the first really ugly bug prevented the priority from working as it should. I fixed that in revision 1.332 of parse.y, that was 2003/02/26. The second one only affected filter rules which do specify queue(s) but do not specify an interface (pass in from ... vs pass in on $if from ...). That I fixed in rev. 1.335 of parse.y (pfctl.h ad pfctl_altq.c cheanged too) on 2003/03/02. so, your snapshot will have the first fix, as this one was in the snapshots even before I committed it (was it this one? man, I have memory leaks), it will not have the second one. -- 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 ack prioritization
On Fri, Mar 07, 2003 at 01:40:31PM +0100, Henning Brauer wrote: (pfctl.h ad pfctl_altq.c cheanged too) need more proofs I cannot type? *sigh* -- 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 ack prioritization
On Thu, 2003-03-06 at 16:23, Jolan Luff wrote: pass in on $int_if proto tcp from any to any port $out_services modulate state queue (q_def, q_pri) # END of pf.rules i'm not sure how relevant this is to your problem, but you have no queue defined on $int_if, so you shouldn't be queuing on it. try making that a vanilla pass rule, reload, and see if it's fixed..? Nope. -J.
Re: ALTQ ack prioritization
Try with just the altq, queue and pass rules from the example. Reload the ruleset and flush all existing state entries (pfctl -Fs), as only newly established connections will be queued according to the new ruleset. Then try a single download and upload over TCP (ftp, http, etc.) concurrently. If that works, you can try the same with your real ruleset, I'd only add the queue (q_def, q_pri) to the pass rules on the external interface, and make sure you're adding it to all of them that create the TCP connections. Daniel
Re: ALTQ ack prioritization
On Thu, Mar 06, 2003 at 03:23:18PM -0600, Jolan Luff wrote: On Thu, Mar 06, 2003 at 10:38:59AM -0500, Jason Dixon wrote: i'm not sure how relevant this is to your problem, but you have no queue defined on $int_if, so you shouldn't be queuing on it. try making that a vanilla pass rule, reload, and see if it's fixed..? this is irrelevant; if no queues are defined the otherwise existing fifo queue is used. jason, there were two nasty bugs in pfctl wrt this; one may affect you. make sure you have a very -current pfctl ... -- 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 ack prioritization
On Thu, 2003-03-06 at 16:37, Daniel Hartmeier wrote: Try with just the altq, queue and pass rules from the example. Reload the ruleset and flush all existing state entries (pfctl -Fs), as only newly established connections will be queued according to the new ruleset. Then try a single download and upload over TCP (ftp, http, etc.) concurrently. If that works, you can try the same with your real ruleset, I'd only add the queue (q_def, q_pri) to the pass rules on the external interface, and make sure you're adding it to all of them that create the TCP connections. I wish I could figure out what happened. I did what you suggested, it worked. I added back my other rules, it worked. So far as I can tell, it was simply a matter of clearing the state table. Odd. I forgot to mention, I'm running -snapshot from 3/2/03. It doesn't look like what happened to me was caused by any bugs (that Henning has mentioned in the meantime), but I'm curious... were any of those bugs fixed after my snapshot? Thanks, -J. P.S. Here are my stats: (250Kb) queue q_pri priority 7 [ pkts: 38789 bytes:2594742 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue q_def priq( default ) [ pkts: 20680 bytes: 27243052 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ]
Re: Altq control error
On Thu, Feb 27, 2003 at 01:09:54PM -0500, Jason Dixon wrote: This appears to work fine. However, if I add control to the std queue, a flush/reload of PF tells me this: pfctl: DIOCADDALTQ: Invalid argument I'll look into this shortly. however, the need for the control keywork is very questionable to me. -- 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
http://www.deadly.org/article.php3?sid=20021119013615
and
http://marc.theaimsgroup.com/?l=openbsd-cvsm=103765983111026w=2
On Tue, Feb 25, 2003 at 05:44:30PM -0500, David Chubb wrote:
Quick question: Is ALTQ implemented in the stable branch of 3.2? Or do I
have to update to -current?
--
Xavier Santolaria [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
perl -we '$|=1;print 1;@a=qw(\ | / -);while(){for($i=0;$i@a;$i++)
{print\b$a[$i];select undef,undef,undef,.1}}print\n'
RE: ALTQ
looks like it made -current after the freeze on 3.2 - so get a 3.3 CD when they ship. didn't play with CVS so I could be wrong! but I don't think you could play with ALTQ+PF in 3.2, only -current. there are answers that shouldn't make you think...and lookup a purchase and cross reference it with a posting - depending on the phase of the moon. -Original Message- From: David Chubb [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 3:45 PM To: [EMAIL PROTECTED] Subject: ALTQ Quick question: Is ALTQ implemented in the stable branch of 3.2? Or do I have to update to -current?
RE: ALTQ
Thanks. Updating to -current. We are using this for part of a testing environment to simulate some adverse network conditions so it doesn't have to be entirely stable. Is there a good place to go find what correct syntax for all the different ALTQ options? (And any gotcha's for the implementation under PF?) --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 4:29 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: ALTQ looks like it made -current after the freeze on 3.2 - so get a 3.3 CD when they ship. didn't play with CVS so I could be wrong! but I don't think you could play with ALTQ+PF in 3.2, only -current. there are answers that shouldn't make you think...and lookup a purchase and cross reference it with a posting - depending on the phase of the moon. -Original Message- From: David Chubb [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 3:45 PM To: [EMAIL PROTECTED] Subject: ALTQ Quick question: Is ALTQ implemented in the stable branch of 3.2? Or do I have to update to -current?
Re: ALTQ
* David Chubb [EMAIL PROTECTED] [030226 15:41]: Updating to -current. We are using this for part of a testing environment to simulate some adverse network conditions so it doesn't have to be entirely stable. Is there a good place to go find what correct syntax for all the different ALTQ options? (And any gotcha's for the implementation under PF?) How about pf.conf(5) and /usr/share/pf? There will also be some very simple examples in the default pf.conf, but I haven't committed that yet. If you see something wrong in the docs, not explained well enough, or missing let us know immediately so we can fix it in time for the 3.3 release. David
Re: ALTQ...WIKI?
On Wed, 26 Feb 2003 14:57:05 -0700 [EMAIL PROTECTED] wrote: there was some talk of starting a WIKI on PF rulesets, that would be a good place to look! http://www.obsd.pronym.org/wiki/index.php/CompendiumOfPFRules Not much there yet, though. -- Murphy
Re: ALTQ
On Tue, Feb 25, 2003 at 05:44:30PM -0500, David Chubb wrote: Quick question: Is ALTQ implemented in the stable branch of 3.2? Or do I have to update to -current? Hasn't ALTQ been in OpenBSD since 3.0? -Ray-
Re: ALTQ: resizing buffer sizes of queues?
On Sun, Feb 09, 2003 at 11:30:49PM +0100, Hendrik Scholz wrote:
Hi!
I'm running a box for testing and like to limit outgoing traffic on my
DSL line.
My setup looks like this:
altq on foo0 cbq bandwidth 10Mb queue { std, test}
foo0? damn, my secret diff must have leaked.
queue std bandwidth 100% cbq (default borrow)
queue test bandwidth 6Kb cbq (red)
pass out quick on foo0 proto tcp from any to 1.2.3.4 \
keep state queue test
When transfering data to 1.2.3.4 I see burst of around 140kB in tcpdump
and then no traffic for some time.
Overall when transfering the speed won't go below ~35kbyte/s.
I've played around with qlimit and cbrsize but it didn't help.
well 6k is just a little _too_ low for a 100Mb interface (I presume it is
one). the resolution isn't that high I think.
tho, 10k worked somewhat good for me on a 100Mb card - don't expect a too
close match on such absurd low values, as said, the time resoltion is limited.
Is there any way to limit the speed to 6kB/s?
Is there a way to define custom queue sizes with altq/pf just like altq
itself allows?
we don't have support for the more obscure options in... we're pretty sure
nobody uses them.
which, exactly, do you miss and why? perhaps we really missed something.
And last but not least: Is there a altqstat like program?
pfctl -vvsq
--
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: resizing buffer sizes of queues?
Henning Brauer wrote: well 6k is just a little _too_ low for a 100Mb interface (I presume it is one). the resolution isn't that high I think. tho, 10k worked somewhat good for me on a 100Mb card - don't expect a too close match on such absurd low values, as said, the time resoltion is limited. Cranking HZ would help here, but this doesn't seem to work on i386 at least. -d
Re: altq, ssh, and tos
On Mon, Dec 23, 2002 at 01:39:04PM +0100, Henning Brauer wrote: On Sun, Dec 22, 2002 at 11:24:57PM -0500, Michael Lucas wrote: When I add a ToS field to that same rule, it appears that that rule is not being processed; instead, it uses the default pass all rule and queue. My first thought is that the ToS is wrong, but it's taken right from Henning Brauer's altq/pf integration message, and I'm assuming he's infallible. There's probably some subtlety that I'm missing. yeah, the subtlety you're missing is that I'm not infallible ;-) Well, *my* worldview has just taken a nasty shock. So, just to confirm: That syntax would be correct for a protocol that *did* set the ToS, i.e., pass out proto tcp from ($ExtIf) to any port $Port keep state tos 0x10 queue blah the docs have been fixed in the meantime ;-) Ah. Well, all right then. It was late anyway, and I really did need to go to bed, so it's just as well. ;-) ==ml -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/
Re: altq, ssh, and tos
On Sun, 22 Dec 2002 23:24:57 -0500, Michael Lucas wrote: So, above, the SSH rule is hit and is used. Now I go to the SSH rule, and I add the ToS field like so: pass out inet proto tcp from ($ExtIf) to any port 22 keep state tos 0x10 queue ssh Per various documentation I've read, this is the ToS for an interactive SSH session. The rest of the rules remain unchanged. Well, very limited testing indicates that ssh sets the type of service after the connection is made. In particular, tos is *not* set in the initial SYN packet, thus your rule is not matched. scp and sftp don't set tos early, either. It seems to me that ssh is not doing the right thing here; it should determine the type of service that it will use and set it before it sends the first SYN. -- Kyle R. Hofmann [EMAIL PROTECTED]
Re: altq, ssh, and tos
snip When I add a ToS field to that same rule, it appears that that rule is not being processed; instead, it uses the default pass all rule and queue. My first thought is that the ToS is wrong, but it's taken right from Henning Brauer's altq/pf integration message, and I'm assuming he's infallible. There's probably some subtlety that I'm missing. snip Can't remember where I read this, but apparently the new format is ...port 22 keep state label ssh queue(ssh_bulk, ssh_interactive) (That's how it's running now on my desktop). I believe this had to do with the ToS changing after connection was created. Seems to work here. Anyone got any good testing / reporting tools for altq in pf? -- Craig
Re: altq and pf
On 19/11/2002, Stefan Sonnenberg-Carstens [EMAIL PROTECTED] wrote To
[EMAIL PROTECTED]:
Can some of you hackers show us some examples of the syntax style ?
look into latest pf.conf.5 on CVS, just committed the BNF
more 'talk' in cvs soon
example:
ext_if = lo0
altq on $ext_if scheduler cbq bandwidth 10Mb queue { deflt, http, ssh, mail }
queue deflt bandwidth 10% priority 0 cbq(default ecn)
queue http bandwidth 50% priority 5 cbq(red, ecn) \
queue { http_vhosts, http_cust1 }
queue http_vhosts bandwidth 40%
queue http_cust1 bandwidth 1Mb
queue mail bandwidth 10% priority 1
queue ssh bandwidth 100Kb priority 7 cbq(borrow)
pass in on $ext_if inet proto tcp from any to $web port 80 keep state queue http
pass in on $ext_if inet proto tcp from any to $webvhost port 80 keep state queue
http_vhosts
pass in on $ext_if inet proto tcp from any to $webcust port 80 keep state queue
http_cust1
pass out on $ext_if inet proto tcp from any to any port 22 keep state queue ssh
pass in on $ext_if inet proto tcp from any to any port 25 keep state queue mail
Re: altq and pf
On Tue, Nov 19, 2002 at 02:27:14PM +0100, Stefan Sonnenberg-Carstens wrote: Can some of you hackers show us some examples of the syntax style ? I'll add an example to the tree soonish. and trim your .sig please ;-)
Re: altq and pf
There's also some good stuff here:
http://www.muine.org/~hoang/openpf.html#qos
-J.
On Tue, 2002-11-19 at 08:37, Philipp Buehler wrote:
On 19/11/2002, Stefan Sonnenberg-Carstens [EMAIL PROTECTED] wrote To
[EMAIL PROTECTED]:
Can some of you hackers show us some examples of the syntax style ?
look into latest pf.conf.5 on CVS, just committed the BNF
more 'talk' in cvs soon
example:
ext_if = lo0
altq on $ext_if scheduler cbq bandwidth 10Mb queue { deflt, http, ssh, mail }
queue deflt bandwidth 10% priority 0 cbq(default ecn)
queue http bandwidth 50% priority 5 cbq(red, ecn) \
queue { http_vhosts, http_cust1 }
queue http_vhosts bandwidth 40%
queue http_cust1 bandwidth 1Mb
queue mail bandwidth 10% priority 1
queue ssh bandwidth 100Kb priority 7 cbq(borrow)
pass in on $ext_if inet proto tcp from any to $web port 80 keep state queue http
pass in on $ext_if inet proto tcp from any to $webvhost port 80 keep state queue
http_vhosts
pass in on $ext_if inet proto tcp from any to $webcust port 80 keep state queue
http_cust1
pass out on $ext_if inet proto tcp from any to any port 22 keep state queue ssh
pass in on $ext_if inet proto tcp from any to any port 25 keep state queue mail
