Date: Sat, 26 May 2001 07:31:01 -0700 (PDT) From: pekkas@netcore.fi To: freebsd-gnats-submit@FreeBSD.org Subject: kern/27661: >1000 ipfw rules and heavy traffic crash the system Message-ID: <200105261431.f4QEV0b32664@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 27661 >Category: kern >Synopsis: >1000 ipfw rules and heavy traffic crash the system >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 26 07:40:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Pekka Savola >Release: 4.3-STABLE >Organization: Netcore >Environment: FreeBSD xxx.org 4.3-STABLE FreeBSD 4.3-STABLE #4: Thu May 10 14:00:09 EDT 2001 root@xxx.org:/usr/obj/usr/src/sys/DEN i386 >Description: See and the threads mentioned there: http://docs.freebsd.org/cgi/getmsg.cgifetch=856687+0+archive/2001/freebsd-stable/20010520.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. >How-To-Repeat: Add a lot of ipfw rules traffic must pass through. Generate _loads_ of traffic (20+ Mbit/s). Wait for a few hours. >Fix: Rearrange the ipfw rules (does not fix the _real_ problem, ie. the system should not crash like this, without any errors, though). >Release-Note: >Audit-Trail: >Unformatted: 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?200105261431.f4QEV0b32664>