Date: Mon, 28 May 2001 00:45:40 +0300 (EEST) From: Pekka Savola <pekkas@netcore.fi> To: Bill Fumerola <billf@mu.org> Cc: <freebsd-bugs@FreeBSD.org> Subject: Re: kern/27661: >1000 ipfw rules and heavy traffic crash the system Message-ID: <Pine.LNX.4.33.0105280032190.25510-100000@netcore.fi> In-Reply-To: <20010527162534.J37979@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 May 2001, Bill Fumerola wrote:
> On Sun, May 27, 2001 at 11:23:18PM +0300, Pekka Savola wrote:
> > On Sun, 27 May 2001, Bill Fumerola wrote:
> > > On Sat, May 26, 2001 at 11:20:02PM -0700, Pekka Savola wrote:
> > >
> > > > Subject: Re: kern/27661: >1000 ipfw rules and heavy traffic crash the system
> > >
> > > I've put 3000 non-matching (and counting+matching) rules on systems
> > > while pushing max traffic before without locking up.
> >
> > I'm sure you're talking about serious traffic here, countable in
> > dozens of megabits, as this appears to be a requirement in this scenario.
>
> At one point, two machines chatting over gig-E, at another point using lo0.
> All of my tests were done with [n]ttcp.
Also assuming you kept at it for a few hours.
If this is so, the problem is probably not mere traffic volume; userland
becoming non-responsive _could_ hint at some other problems, perhaps with
the amount of different separate connections maybe (dunno if that is
testable with ttcp and friends, I think it creates just one multiplexed
conn).
Over two weeks the stats are like:
00150 4927834474 3225299285639 Sun May 27 17:33:29 2001 allow tcp from any
to any established
02600 12154179 613341777 Sun May 27 17:34:40 2001 allow tcp from any
to any 80 in recv fxp0 setup
[ probably not significant: all the 500+ rules have the same rule number
(easy to delete all of them at once) ]
Of course, when freezes happen after a couple of hours, these are
naturally signifcantly less.
Also.. when you tested this, did you monitor the mbuf usage? They were
not running out here, but I'm hoping ttcp would be able to create a
similar mount of mbuf/mbuf cluster usage .. there might be some
connection.
The stats are usually like:
7687/10064/65536 mbufs in use (current/peak/max):
6514 mbufs allocated to data
1173 mbufs allocated to packet headers
6304/8254/16384 mbuf clusters in use (current/peak/max)
19024 Kbytes allocated to network (38% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
> So its not happening anymore? You can afford for the production
> machine to go down randomly when it hits enough traffic but not
> in a controlled environment (or did you just shorten/simplify your
> ruleset)?
I've changed the ruleset; I've put all of these 500+ rules after the
established rule and have had zero problems; before, the system would
crash every two days or so, now it has been up for two weeks no problems.
> In any event, until I get a scenario in which I (or someone else) can
> reproduce this (and I've done my tests with SMP w/o trouble, it was just
> a hunch), I have nothing more to say regarding this bug.
Yeah, I realize this :-/.
--
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?Pine.LNX.4.33.0105280032190.25510-100000>