From owner-freebsd-stable Fri May 18 7:32:34 2001 Delivered-To: freebsd-stable@freebsd.org Received: from netcore.fi (netcore.fi [193.94.160.1]) by hub.freebsd.org (Postfix) with ESMTP id 47F6137B42C for ; Fri, 18 May 2001 07:32:29 -0700 (PDT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4IEWRD23397 for ; Fri, 18 May 2001 17:32:28 +0300 Date: Fri, 18 May 2001 17:32:27 +0300 (EEST) From: Pekka Savola To: Subject: 4.3-S: >1000 ipfw rules and heavy traffic crash the system Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello all, This is related to '4.3-S: No buffer space available' thread here two weeks ago: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=965879+0+archive/2001/freebsd-stable/20010506.freebsd-stable 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. ==> Of course, adding >1000 non-matching rules is stupid, but that is not ==> the point. The system should not crash this way, without any error ==> messages. The crash causes all userspace to become totally non-responsive: ping and traceroute from the outside work ok, but all existing connections become non-responsive. New TCP establishment work until when you'd have to communicate with the daemon. Console keyboard does not react to CTRL-ALT-DEL. This is _not_ caused by mbuf/mbuf cluster usage; I have a cronjob saving these as a debugging information every two minutes, and there was no significant increase there; peak had never gone more than the half of the maximum. The same crash has happened with smaller number of non-matching rules too; e.g. 600. Usually took longer this way. This had happened like 3-4 before I realized what was going wrong. Probably not relevant, but after every crash, there were usually a _lot_ of FS inconsistancies. Please Cc:. -- 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-stable" in the body of the message