I used to have a mid prioritized default queue. However, whenever you
reload the pf rules (pfctl -f), it puts all already defined states in the
default queue. Overtime things will even out, but basically the traffic
shaping is broken for hours any time the rules are reloaded, unless you
decide to flush the state table (not a workable option for me). Obviously,
since you are reloading all rules, the queueing rules may have changed, so
you need to stick everything in a default queue (or write a lot of code to
decide how to map the old queues to the new queues).
I tried reloading just the filter rules (pfctl -Rf), but it does the same
thing, except it is worse because not only do all already defined states go
into the default queue, but all states created in the future will go into
the default queue. I don't know whether this is a bug or expected behavior.
I think it is a design flaw, because if the queue rules haven't changed, and
all states should stay in the same queue, and packets should continue to be
assigned to queues just as before.
Having the default queue being the lowest priority one was the best solution
in regards to changing rulesets. With the default queue being the lowest
priority one, reloading the rules brings everything to an equal playing
field. As states are created and dropped, higher priority traffic will get
priority over lower priority traffic. However, at no point will you have
lower priority traffic given precedence over higher priority traffic (at
worst, low priority traffic and high priority traffic are treated equally).
If you have a priority 7 default queue, and priority 1 priority traffic
keeps its connection open for a lot longer than priority 5 traffic, you will
get to the point that lower priority traffic (priority 1) is given
precedence over higher priority traffic (priority 5).
Basically, I see it this way: If pf is going to put packets/frames in a
queue, it should give you the ability to choose which queue. For all IP
packets, this is possible. For ethernet frames, this is not. I know the pf
was designed specifically for IP filtering, and that writing filtering code
for other layer 3/4 protocols (IPX/SPX, NETBEUI, etc.) is a waste of time.
However, I propose that pf be expanded to include ethernet (and at least
arp) frames, since I'd wager that there are about the same number of people
using ethernet/arp as using IP. Probably the best way to do this would be
to give the option to use the ethernet frame type in assigning non-IP
traffic to queues. If this isn't possible, there should be an a single pf
rule that assigned the queue for non-IP traffic:
pass proto other queue highestpriority
----- Original Message -----
From: "Henning Brauer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 21, 2003 9:15 AM
Subject: Re: PF, Queueing, Bridging, and ARP frames
> On Fri, Jun 20, 2003 at 10:23:56PM -0700, Jeremy Evans wrote:
> > Since they are layer 2 frames and not layer 3/4 packets, there doesn't
seem
> > to be anyway to change which in queue they are placed. Is there any way
to
> > assign arp frames to a different queue?
>
> everything that isn't but into a specific queue by pf goes to the
> defau lt queue.
> your solution, obviously, is to have a mid-priorized default queue,
> and explicitely put everything that you don't sort to specific queues
> in pf into a low priority queue.
>
> --
> 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)
>
