[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    RE: State/queue question
From:       "Peter Huncar" <hunci () centrum ! sk>
Date:       2005-04-24 21:47:35
Message-ID: 20050424220429.3CDCFA9 () mail ! chemnet ! sk
[Download RAW message or body]

Sure, this mail helped me A LOT ;o) although it wasn't for me ;) I'm
meditating about how to create rules and/or queues for my router for a long
time.

"I misunderstood how this worked as well" ;o)

Thank you ;o)

							hunci

> -----Original Message-----
> From: owner-pf@benzedrine.cx [mailto:owner-pf@benzedrine.cx] On Behalf Of
> Kelley Reynolds
> Sent: Sunday, April 24, 2005 2:02 AM
> To: pf@benzedrine.cx
> Subject: Re: State/queue question
> 
> 
> On Apr 23, 2005, at 9:06 AM, Henning Brauer wrote:
> 
> > * J. Martin Petersen <jmp.lists@alvorlig.dk> [2005-04-23 10:49]:
> >> Henning Brauer wrote:
> >>> * Kelley Reynolds <schnozzy@verbotenplanet.net> [2005-03-21 19:40]:
> >>>
> >>>> This has come up a few times on the list, and I was wondering how
> >>>> difficult it would be to alter the pf syntax so that a stateful
> >>>> rule on a firewall could apply queues on two interfaces so that
> >>>> bidirectional queueing can be done while tracking state?
> >>>>
> >>>> I believe (and please correct me if I'm wrong) that to get
> >>>> bi-directional queueing, one must have a seperate rule per
> >>>> interface and not keep state since that would be a single rule
> >>>> (this limiting the state-associated packets to a single queue, one
> >>>> interface or the other)
> >>>
> >>>
> >>> huh? you should create state and just create queues by the same
> >>> names n
> >>> different interfaces, it'll Just Work
> >>
> >> Was this introduced recently?
> >
> > no.
> >
> >> When I try something something like
> >>
> >> 	altq on $mci_if cbq bandwidth 28Mb qlimit $qs queue { serv bulk}
> >> 	  queue serv bandwidth 20% priority 6 cbq(borrow)
> >> 	  queue bulk bandwidth 80% priority 5 cbq(borrow)
> >>
> >> 	altq on $mbh_if cbq bandwidth 28Mb qlimit $qs queue { serv bulk}
> >> 	  queue serv bandwidth 20% priority 6 cbq(borrow)
> >> 	  queue bulk bandwidth 80% priority 5 cbq(borrow)
> >
> > you are specifying teh queues twice.
> >
> >  	altq on { $mci_if $mbh_if } cbq bandwidth 28Mb qlimit $qs queue {
> > serv bulk}
> >  	  queue serv bandwidth 20% priority 6 cbq(borrow)
> >  	  queue bulk bandwidth 80% priority 5 cbq(borrow)
> >
> > will work, or you can limit queue specifications to a certain
> > interfaces as well, aka queue blah on $someinterface
> 
> I misunderstood how this worked as well (and in fact, I have changes to
> the documentation pending for the FAQ for this exact question as per
> Henning's owed favor) but it's all very simple.
> 
> Making a queue is exactly like creating a rule. It assumes all
> interfaces unless you specify an interface like:
> 
> queue serv on $mci_if bandwidth ...
> queue serv on $mbh_if bandwidth ...
> 
> Now, if you want the attributes of those queues to be the same (same
> bandwidth, same priority, same whatever), you can just omit the
> interface bit and it'll make a queue with said names on every
> interface.
> 
> Now for the truly useful part which is what I was missing: When you
> assign a packet to a queue in a rule, you aren't actually assigning it
> to a queue. All you are doing is giving it a name. For example, you are
> stating "If there is a queue called <queuename> when I'm going out an
> interface, apply it. If not, apply me to the default queue"
> 
> So when traveling out $mbh_if, if there is queue matching the queue
> assigned to the packet, it will go there. Likewise, when traveling out
> $mci_if, if there is a queue name matching the queue assigned to the
> packet, it will go there or failing that, the default queue.
> 
> To doubly reiterate in a slightly different way:
> 
> pass in on $mci_if keep state queue foo
> 
> All you have done there is attach the name 'foo' to packets matching
> this rule. You've done no queueing, no nothing. The check for queueing
> comes later, when this packet is exiting an interface, at which point
> it says "Is there a queue named 'foo' on this interface? If so, go into
> it. If not, go into the default queue."
> 
> There is naturally a more technical way of describing this behavior,
> but you'll have to ask somebody else for that if you really want it.
> 
> Kelley Reynolds
> President
> Inside Systems, Inc.

[prev in list] [next in list] [prev in thread] [next in thread]