Date: Thu, 20 Sep 2001 11:57:46 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: "Marc G. Fournier" <scrappy@hub.org> Cc: Leif Neland <leifn@neland.dk>, freebsd-net@freebsd.org Subject: Re: ipfw problems ... Message-ID: <Pine.BSF.4.21.0109201146260.32403-100000@InterJet.elischer.org> In-Reply-To: <20010920081526.W30377-100000@mail1.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
cool.. Now that you've done it by hand, could you write a script to automate the tree creation? (than we could commit it.. ) Actually Can you show me a sample? It seems to me that you should be able to get the number of filters processed on average to be much less than 100. On Thu, 20 Sep 2001, Marc G. Fournier wrote: > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109201146260.32403-100000>