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