From owner-freebsd-net Thu Sep 20 5:27:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail1.hub.org (webmail.hub.org [216.126.85.1]) by hub.freebsd.org (Postfix) with ESMTP id CF01F37B40D for ; Thu, 20 Sep 2001 05:27:07 -0700 (PDT) Received: from localhost (scrappy@localhost) by mail1.hub.org (8.11.3/8.11.4) with ESMTP id f8KCQuB27370; Thu, 20 Sep 2001 08:26:56 -0400 (EDT) (envelope-from scrappy@hub.org) Date: Thu, 20 Sep 2001 08:26:56 -0400 (EDT) From: "Marc G. Fournier" To: Leif Neland Cc: Subject: Re: ipfw problems ... In-Reply-To: <20010919190035.S34253-100000@arnold.neland.dk> Message-ID: <20010920081526.W30377-100000@mail1.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Our network layout is such that our ipfw box is purely a pass-thru between our router and our network providers router: [our router] <--> [freebsd box running ipfw] <--> [network provider] / \ [CA*Net3] [Commercial] Our CA*Net3 link is something like 50Mb/s, while Commercial is only 12, so we don't want to restrict the traffic to CA*Net3 ... I spent all day yesterday going through the rules, and have it working with: psychopompus# ipfw show | grep skipto | wc -l 248 psychopompus# ipfw show | grep deny | wc -l 31 psychopompus# ipfw show | grep allow | wc -l 1043 psychopompus# And it works ... so now instead of processing >1k rules, it works out to be <100 or so ... On Wed, 19 Sep 2001, Leif Neland wrote: > > > > > Third, take into account that since ipfw takes 'first matching rule > > > wins' approach, you will get performance boost by moving more > > > frequently used and more general rules "up" in the ruleset. For > > > example, if you move the rule from position 700 to 200 packet will be > > > matched only against 200 rules instead of 700. > > > > Thought about, but not possible ... unless I'm mis-understanding something > > ... these rules are the exceptions ... "if none of these b-class networks > > isn't matched, *then* shape the bandwidth for anything not in there" ... > > > Is the machine dying when *adding* the rules or when *using* the rules? > > If your first rule is "ipfw add 100 skipto 32768 ip from any to 1/1" > you will have divided your rules, so networks from 0.0.0.0 to > 127.255.255.255 will be handled by half of the rules, and the rest by the > other half. So instead of traversing 700 rules, an unmatched packet will > only traverse 350. > > Perhaps you could write a (perl?)script, which you feed a list of all the > networks (B's?) and generates the proper rules. > > You could post that as a challenge to your local group of nerds, if you > can find them... > > Also remember that the mask does not need to be "without holes", a mask of > 255.127.255.0 is ok. > But I guess you must either be a computer or autistic to be able to spot > those masks... > > Another idea: is the routing mechanism better to sort by ip than ipfw? > If so, you could route the expensive traffic to the shaper-machine. > > On top of that: is the routing information available from your uplinks? > Perhaps you could get BGP or OSPF-routing information, saving you the > trouble of maintaining the table. > > Also, what happens if you send "expensive" packets to the free uplink? > > Could that be used to having two default gateways with different metric? > Or can this only shift the entire stream between the two gateways? > > > Or you could patch ipfw to be able to use a hash-db :-) > > > Leif > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message