On 2017-04-05, Marko Cupać <marko.cu...@mimar.rs> wrote: > I still haven't found a way to throttle down queues to desired values > without using fixed min and max values.
I haven't done very well with this either. I've had better luck with kernels built with higher HZ but haven't been really happy with it (and what I really want is to be able to limit bandwidth per-ip - with a limited amount of v4 space you can just about manage this with a lot of queue and assignment rules, but that's impossible for ipv6, and even with ipv4 makes it hard to use a decent amount of address space to mitigate against DHCP exhaustion attacks e.g. on public wifi). > Adding NAT to the mix > complicates things further. What about queueing of traffic inside GRE > tunnels in transport mode protected with IPSEC? Where to read about it? The queue is assigned to the PF state, based on the queue name. You can either do this in a "pass" rule or a "match" rule. NAT is easy to cope with using "match" when you take the following into account: : Translation : Translation options modify either the source or destination address and : port of the packets associated with a stateful connection. pf(4) : modifies the specified address and/or port in the packet and recalculates : IP, TCP, and UDP checksums as necessary. : : Subsequent rules will see packets as they look after any addresses and : ports have been translated. These rules will therefore have to filter : based on the translated address and port number. So you can simply do your queue assignment with a "match..queue" rule before the nat-to rule, then the queue rule will be evaluated while the packet still has the pre-NAT address. Also, if you're queueing in both directions (internet->local as well as local->internet) make sure the queues on the different interfaces have the same name, so you can just assign to e.g. "fast". I've often seen examples where people try to use two different names depending on the direction (e.g. "fast_in" and "fast_out") and run into problems when they try to assign to queues. > Optimistic me believes that devs are too busy making stuff work and > have no time to explain it to us poor admins (by means of manpages, > faqs or howtos). But how can I know how to use it if I can't read about > it anywhere? Queues never had the best documentation, I've tried improving it before but didn't manage to write anything that really helped. I think the most useful that I saw was in Jacek Artymiak's "building firewalls" book - but that was for altq and not relevant to newer PF/queues. If someone reading has a queue config that they're happy with, it would be nice to see pf.conf snippets! > Pessimistic me starts to notice that less and less free knowledge can be > found around the 'net. That's exactly the opposite of what OpenBSD is trying to do. > If I want answers to my questions, is the > best way to start saving money for paying OpenBSD consultants hourly > rates for tuition? Where the documentation leaves you with questions, I think the best way is to look at the code, mailing list posts and commit logs and try things out. If you can make any specific suggestions to improve docs, that would be really helpful.
