Understanding where dummynet fits into an ipfw ruleset

Ian Smith smithi at nimnet.asn.au
Sun Jun 29 06:22:41 UTC 2008


On Sat, 28 Jun 2008, Freddie Cash wrote:
 > On Fri, Jun 27, 2008 at 11:14 PM, Ian Smith <smithi at 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 at 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



More information about the freebsd-net mailing list