Date: Sat, 26 May 2001 23:20:02 -0700 (PDT) From: Pekka Savola <pekkas@netcore.fi> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/27661: >1000 ipfw rules and heavy traffic crash the system Message-ID: <200105270620.f4R6K2N70148@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/27661; it has been noted by GNATS. From: Pekka Savola <pekkas@netcore.fi> To: Kris Kennaway <kris@obsecurity.org> Cc: <freebsd-gnats-submit@FreeBSD.org> Subject: Re: kern/27661: >1000 ipfw rules and heavy traffic crash the system Date: Sun, 27 May 2001 09:13:53 +0300 (EEST) On Sat, 26 May 2001, Kris Kennaway wrote: > On Sat, May 26, 2001 at 07:31:01AM -0700, pekkas@netcore.fi wrote: > > > >Description: > > See and the threads mentioned there: http://docs.freebsd.org/cgi/getmsg.cgifetch=856687+0+archive/2001/freebsd-stable/20010520.freebsd-stable > > This URL does not seem to be valid. Hmm, cut'n'paste error perhaps. Again: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=856687+0+archive/2001/freebsd-stable/20010520.freebsd-stable Anyway, these were threads on freebsd-stable: "4.3-S: >1000 ipfw rules and heavy traffic crash the system" (18 May) "4.3-S: No buffer space available" (5 May) > > I noticed that if you create too many ipfw rules, through which extra > > traffic must pass, rather soon you will crash the system. > > > > In this scenario, adding >1000 non-matching rules before the > > standard tcp established rule, and doing 20Mbit/s steady through the > > rules, caused kernel load to go to ~8.0 (Dual P3/866) and after less than > > an hour, crash the system. > > When you say "crash" do you mean "panic" (the usual meaning), or "lock > up"? If the former, please obtain a panic traceback to aid in debugging. lock up. I hope it had paniced, so it could be traceable :-/ > It sounds to me as if this is just a case of giving the system too > much work to do. If it has to spend more time processing a packet > than the time between packet arrival, things are going to go badly. There seems a to be a point of no return there: if some amount of processing is done, the TCP connections do not send new data anymore etc. I haven't monitored what the bandwidth usage is like then, but I suspect it is very little; I have doubts that there is the equally high number of incoming connections then. So, I don't think this is just too slow processing. It looks like too heavy processing triggers some big problem causing the lock-up. > As far as I know ipfw doesn't have an 'exit clause' which drops > packets if they are taking too long to process. I don't know if it > would be easy to add one; the best solution, as you noted, is to not > write inefficient rulesets. I'm not used to (partial) kernel lockup's without any messages printed on console or syslog; these are very difficult to figure out what is causing them. That is why I'd like a "right" solution for this, not just "Don't Do It". Someone is bound to do the same thing sooner or later and wonder about fscking FreeBSD locking up all the time without explanation. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105270620.f4R6K2N70148>