Date: Sun, 29 Jun 2008 16:22:29 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Freddie Cash <fjwcash@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Understanding where dummynet fits into an ipfw ruleset Message-ID: <Pine.BSF.3.96.1080629155935.11273A-100000@gaia.nimnet.asn.au> In-Reply-To: <b269bc570806282234g3b9eaccdgeb85f70808f3357d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 28 Jun 2008, Freddie Cash wrote: > On Fri, Jun 27, 2008 at 11:14 PM, Ian Smith <smithi@nimnet.asn.au> wrote: > > 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. > > No, the rule is needed. Packets passing through the firewall go > through the ruleset twice: once entering the external interface, and > again leaving the internal interface (and vice versa). > > The first rule allows the packet in on the external interface, the > second rule allows it out the internal interface, the third rule > denies all other incoming traffic. Yes. So isn't that working? ipfw queue show? [ cut my longwinded explanation of what you just said above :] > > > 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 know that. I was just trying to use very simplified examples > to understand how the traffic shaping works in conjunction with the > packet filtering. I understand how the queueing works, and have used > it successfully on routers that don't do packet filtering. It's > adding it to existing packet filter rulesets that is making my head > spin. :) And in your subsequent reply to martes@mgwigglesworth.com you said: > Yes, I've read the dummynet and ipfw man pages. Yes, I've read > articles on the 'Net. Yes, I've done google searches. And no, it > still doesn't make sense how queue rules work with packet filter > rules. Hence, why I'm asking here. It's not clear to me what's not working from your example rules above? Given using one_pass=1, that should go. And using one_pass=0, you should only need to also add as say rule 150: 150 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 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? > > No, I want to use queue. I want to create rules to "reserve" > bandwidth for connections to important servers, as we're moving to > more web-based applications, and I want to make sure students surfing > the web don't impact office staff. There will be a single pipe, with > two queues, one weighted at twice the value of the other. That way, > if there is no staff traffic, the students get the whole pipe. If > there is no student traffic, staff get the whole pipe. And if there's > a mix, then staff traffic is prioritised ahead of student traffic. Ok; on rereading your original, I should have realised that. So with a similar set of rules for the other of staff/students that your above example deals with, and the right pipe and queue configs, what remains to do? Sorry to be thick, but I don't see why that wouldn't work .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080629155935.11273A-100000>