Date: Sat, 28 Jun 2008 16:14:15 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-net@freebsd.org, Freddie Cash <fjwcash@gmail.com> Subject: Re: Understanding where dummynet fits into an ipfw ruleset Message-ID: <Pine.BSF.3.96.1080628150610.4653B-100000@gaia.nimnet.asn.au> In-Reply-To: <C283B2D1-5193-4D32-8D38-9D72282F5876@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 Jun 2008, Chuck Swiger wrote: > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > [ ... ] > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > >> apply your > >> deny rules first, as once something matches a pipe rule, it's going > >> to be > >> passed. The tradeoff is that the accounting/fairness of traffic is > >> less > >> accurate but the firewall ruleset runs faster... > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > To add traffic shaping to the following, using one_pass=1: > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Would be: > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Or am I way off here? :) > > Hmm. If you have one_pass set, I believe that rule 200 would become > superfluous. If it was off, rule 200 would be needed to permit > traffic through. I'm keen to be certain about this myself. I think that one_pass only affects the packet on the current pass, in this case on the incoming pass from ip_input at rule 100 above. So if one_pass is set, the packet is queued (and accepted in) and the search terminates, but with one_pass off, the packet is reinjected at rule 200 when it leaves the pipe after its limitation and/or delay, and would need to be specifically allowed. However I don't think that affects the outgoing pass, ie after routing the packet still has to go through the firewall again (from ip_output), so in this case it will be allowed if it's going out to 2.2.2.2 via em1, else is denied at rule 300. Another option might be to only apply pipe/queue actions to 'out' rules, but mixing that with both 1:many and 1:1 NAT will complicate matters .. > However, queue rulesets are used to classify traffic > into different bins; then then get pulled out of the bins with packets > waiting is proportion to the weights configured via something like: > > ipfw queue 1 config pipe 1 weight 10 > > ie, you have to attach queue(s) to a pipe for this classification or > sorting to be meaningful. Yes I suspect Freddie might want to use pipe rather than queue here too, if just for bandwidth limitation rather than weighted queueing by type of traffic? And is it only wanted for managing the inbound traffic? It's quite confusing at first that pipe and queue are both ipfw 'actions', and are also terms used as pipe and queue configuration parameters, as in a queue definition specifies a particular 'pipe pipe_nr' and that 'queue' is used to specify a pipe's queue size .. Caveat: I'm only using pipes so far, and on a bridge, not a router, where you only get one shot at allow/deny/pipe on packets incoming through bdg_forward, ie no 'out' rules, for bridged packets anyway. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080628150610.4653B-100000>