On 2014-02-13, Peter N. M. Hansteen <pe...@bsdly.net> wrote:
> On Wed, Feb 12, 2014 at 09:18:09PM -0800, Scott Vanderbilt wrote:
>> This is running OpenBSD 5.5-beta on i386 (Jan. 22 snapshot).
>
> 5.5-beta has the new traffic shaping code in it, and there was an
> irresolvable conflict over the 'queue' keyword.
>
> In the general case I would say you could opt to switch over
> to the new queues system (which requires a bit of man page reading
> or waiting until the refreshed Book of PF that I'm working on comes out)
> or for now do a simple search and replace to replace 'queue' with
> 'oldqueue' and keep most ALTQ setups intact until you have read up on
> the new system a bit. But seeing that you use only priorities, you could
> skip the queueing for now and just use the priorities that we've
> had since OpenBSD 5.0.
>
> This means, ditch this part
>
>> altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
>> queue q_pri on $ext_if priority 7
>> queue q_def on $ext_if priority 1 priq(default)
>
> and replace this with
>
>> match out on $ext_if from $localnet nat-to ($ext_if) queue (q_def, q_pri )
>
> something like
>
> match out on $ext_if from $localnet nat-to ($ext_if) set prio (3, 6)
>
> (the default priority is 3, do the two-priority trick with priorities only,
> no queues necessary)
This is quite a different rule; the old one limits outgoing bandwidth to
100Kb/s and _within that 100Kb/s_ it prioritizes certain traffic. This
suggested replacement isn't throttling the packets going out of the
interface at all, so unless there's a huge amount of data being sent, the
priorities aren't going to come into play. If this is the common case
of queueing on a firewall that's behind a modem connected to a WAN link
that is slower than the ethernet interface, you're just going to fill
the modem's buffers..
I'm not sure how "set prio" fits together with the new queueing code yet,
I've played a bit but don't have a good way to visualize the traffic
and get a good feel for how it works (I used to use ttt to get nice
live-updating graphs per-flow when testing queue configuration, but that
needs tkBLT which doesn't run with current Tk versions; everything else
I've found that can produce graphs useful for this is after-the-fact,
which makes it harder to see the effect of config changes on a live
network).
