On 2008/02/25 23:22, Adam Retter wrote: > All of the examples that I have seen use two queues, one on the > external interface and one on the internal interface. The example > given in the PF manual on the OpenBSD website itself also shows a 2 > queue setup - http://www.openbsd.org/faq/pf/queueing.html#example1
you can have queues on >1 interface with the same name. and queue assignment doesn't have to happen on the interface holding the queue. if you're queueing on internal+external interfaces, this can make it simpler to get filter rules written which assign traffic to the queues you want. I tried to explain this well enough to get it into pf.conf(5) but haven't managed to come up with anything suitable yet (it probably needs a bunch of existing text being rewritten rather than just adding something new ..) this post might help: From: Henning Brauer <[EMAIL PROTECTED]> Date: Mon, 9 Oct 2006 14:52:03 +0200 To: [email protected] User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: Request for feature: queue assignment for back packets (Was: ACKs queueing) * Federico Giannici <[EMAIL PROTECTED]> [2006-10-09 12:51]: > Henning Brauer wrote: > >* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 20:32]: > >>I solved my case in a good way, but I'm currently not using states. I > >>think that a general, intuitive and efficient solution could be useful. > >> > >>The problem: queue assignment of "back" packets of TCP flows when "keep > >>state" is used and queues are used in both directions. Currently the > >>only solution seems to be to (almost) replicate the same rules for both > >>interfaces ("in" and "out"). So the same rules are evaluated two time: > >>more use of CPU and more rules to maintain. > > > >this is untrue, you can just create queues with the same names on both > >interfaces. queue assignment does not have to happen on the interface > >where the queue lives. > > That's really interesting. > > And now the "on _interface_" parameter of the "queue" command start to > make sense... well, let me explain (again. I did this before, must be in the archives). when a rule matches that has a queue assignment, the packet gets tagged with the queue name (not really the name, but that is what it comes down to). the packet then travels through the system like it always does. when it hits the outboind queuing stage (i. e. queueing on the interface where it will leave the machine), the altq routines check for the tag. if it is not there, the packet goes to teh default queue. if the tag is there, altq checks wether a queue with that name exists. if yes, the packet is queued there, otherwise it is put into the default queue. you see, it is not like the packets gets put into a queue when a pf rule assigns it. it happens way later. and thus your cas eis already covered. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
