On 2014-08-04, Eric Dilmore <[email protected]> wrote: > I just set up a new OpenBSD 5.5 gateway for a small nonprofit. The > gateway has one external interface and one internal, with the internal > network split into several VLANs: one for secure traffic, one for > guests, one for internal phones, and one for our external Asterisk phone > server. > > I'm trying to use queues to set up QoS for the Asterisk server. There is > limited bandwidth in our location, and we would like to ensure that the > Asterisk server has priority over other traffic. I would prefer a > bandwidth specification over a simple priority, but either would be > fine. > > However, I believe that pf queues are tied to an outbound interface. > None of the rules I have attempted on the internal interface have > matched at all. I can specify each vlan explicitly, but the internal > interface itself doesn't seem to match any packets. tcpdump shows > traffic passing both in and out when I specify the internal interface. > > I am confused about the relationship between the physical interface and > the vlan interfaces in pf. I would also like to know if there are any > suggestions for how to set up the queues in order to provide QoS for > phone traffic. > > My current pf.conf is hosted in a gist here: > https://gist.github.com/geppettodivacin/8fc8dc044b122154d137
1. Don't use different _in and _out names, use syntax like "queue foo on em0" and "queue foo on em1". That way you assign packets to the correct queues on both interfaces in one step with something like "match to port 53 queue fast". The queue name is associated with the PF state; packets matching that state get assigned to that queue. 1a. Confirm your queue setup by running "systat queue" (as root) and making sure that you see packets assigned to the various queues that you have configured. 2. In my (admittedly very limited) testing with the new queueing system, it hasn't done very well with low bandwidth queues (ADSL type speeds) that used to work OK with altq (symptom, packets being assigned to queues as expected, but rates not being controlled). Next step in my testing there will be to build a kernel with a higher HZ value (faster timer) but I haven't got round to that yet.
