Understanding where dummynet fits into an ipfw ruleset

[Freddie Cash]

On Sat, Jun 28, 2008 at 11:22 PM, Ian Smith <smithi at nimnet.asn.au> wrote:
> It's not clear to me what's not working from your example rules above?

I never said anything wasn't working.  I was just looking for
information to better understand how things work together, and to get
a general feeling of where the queue rules would have to go.

> 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

I'm starting to better understand how one_pass affects things.  And I
think I get, now, where to put the queue rules.

I won't be doing any of the actual testing or implementation until
July.  I was just looking for more info on how to set things up.

>  > > 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 ..

I never said it wouldn't (or didn't) work.  :)

-- 
Freddie Cash
fjwcash at gmail.com