From the faq:
The syntax for the queue directive is:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] \
scheduler ( sched_options ) { queue_list }
Specify on which interface you are assigning each queue.
queue bob on fxp0 ....
queue bob on fxp1 ....
Kelley Reynolds
President
Inside Systems, Inc.
On Jan 12, 2011, at 11:40 AM, Bonnie Packet wrote:
> If you look at the posting from yesterday, you'll see the attempted
> setup is on two different interfaces, yes. That's been the case from
> the start.
>
> However, when I try to do the setup suggested by folks here several
> times now (same queue name repeated on another interface) pf complains
> bitterly and refuses to load the rules (see below). This is on an old,
> old OpenBSD 3.9 system - does anyone know if something changed in
> later releases to allows the the same queue name on multiple
> interfaces? (I looked through all the change logs up through the
> current 4.8, but didn't see anything.) Or do I have the syntax wrong?
>
>
> #cat /etc/pf.conf
> ..
> altq on $int_if cbq bandwidth 5000Kb queue { std, slow, fast, tcpack }
> queue std bandwidth 1200Kb priority 1 cbq(default borrow)
> queue slow bandwidth 400Kb priority 0 cbq(ecn)
> queue fast bandwidth 3300Kb priority 2 cbq(borrow)
> queue tcpack bandwidth 100Kb priority 3 cbq(borrow)
>
> altq on $ext_if cbq bandwidth 900Kb queue { std, slow, fast, tcpack }
> queue std bandwidth 400Kb priority 1 cbq(default borrow)
> queue slow bandwidth 50Kb priority 0 cbq(ecn)
> queue fast bandwidth 400Kb priority 2 cbq(borrow)
> queue tcpack bandwidth 50Kb priority 3 cbq(borrow)
> ....
>
> #./rc.pf
>
> queue std already exists on interface rl0
> /etc/pf.conf:45: errors in queue definition
> queue slow already exists on interface rl0
> /etc/pf.conf:46: errors in queue definition
> queue fast already exists on interface rl0
> /etc/pf.conf:47: errors in queue definition
> queue tcpack already exists on interface rl0
> /etc/pf.conf:48: errors in queue definition
> pfctl: Syntax error in config file: pf rules not loaded
>
>
>
> On Jan 12, 12:01=A0am, jhe...@logn.net (Jason Healy) wrote:
>> On Jan 11, 2011, at 1:35 AM, Bonnie Packet wrote:
>>
>>> Note that I know PF reasonably well and have altq queuing / rate
>>> limiting working perfectly already in ONE direction (right now, the
>>> high-bandwidth download side) - I just can't figure out how to get it
>>> working in both directions, up and down, simultaneously. =A0I've beat m=
> y
>>> head against TFM and nothing seems applicable - though this can't be
>>> an uncommon need...?
>>
>> Are you creating your in/out queues on a single interface? =A0If so, that=
> might be your problem.
>>
>> We have our box set up with both a "lan" interface and a "wan" interface.=
> =A0The "outbound" queues are children of the "wan" interface, but the "inb=
> ound" queues are children of the "lan" interface. =A0The folklore you hear =
> about "only being able to shape outbound traffic" is sort of true; you can =
> only shape the packets as they leave the PF box. =A0However, as packets tra=
> verse your box, they come IN, get processed, and then go OUT to be delivere=
> d, so you always have the opportunity to shape them. =A0You just need to ma=
> ke sure you're doing it at the right end.
>>
>> Essentially, for "inbound" traffic (from the internet to your lan), PF qu=
> eues (and possibly drops) packets *just before* they would be delivered to =
> your boxes on the inside. =A0It's a little tragic (as others have mentioned=
> ) since those packets have already consumed your DSL bandwidth only to be d=
> ropped, but it's necessary to force the congestion-control to slow the flow=
> for future packets.
>>
>> With a 2-interface 2-queue setup, we've been able to manage asymmetrical =
> bandwidth amounts. =A0We now have a symmetric connection, but I know we had=
> one working back when we were on a 16up/2down cable connection...
>>
>> Jason
>>
>> --
>> Jason Healy =A0 =A0| =A0 =a0jhe...@logn.net =A0 =A0| =A0http://www.logn.n=
> et/
