🚀 go-pugleaf

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 am, 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.  I've beat my
> > 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?  If so, that might be your problem.
>
> We have our box set up with both a "lan" interface and a "wan" interface.  The "outbound" queues are children of the "wan" interface, but the "inbound" queues are children of the "lan" interface.  The 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.  However, as packets traverse your box, they come IN, get processed, and then go OUT to be delivered, so you always have the opportunity to shape them.  You just need to make sure you're doing it at the right end.
>
> Essentially, for "inbound" traffic (from the internet to your lan), PF queues (and possibly drops) packets *just before* they would be delivered to your boxes on the inside.  It's a little tragic (as others have mentioned) since those packets have already consumed your DSL bandwidth only to be dropped, 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.  We 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    |    jhe...@logn.net    |  http://www.logn.net/