From owner-freebsd-arch Tue Nov 7 14:51: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 56B6F37B479; Tue, 7 Nov 2000 14:50:57 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA52720; Tue, 7 Nov 2000 23:50:56 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. References: <28041.973635706@critter> From: Dag-Erling Smorgrav Date: 07 Nov 2000 23:50:55 +0100 In-Reply-To: Poul-Henning Kamp's message of "Tue, 07 Nov 2000 23:21:46 +0100" Message-ID: Lines: 47 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > IP: > Yellow: > Expire cloned routes faster. > Stop generating ICMP packets. > Stop forwarding packets. + Stop passing packets to bpf (which IIRC needs to duplicate them, which eats mbufs) > Red: > Expire all cloned routes now. + If running dummynet, drop everything that enters a pipe as if that pipe was full. > TCP: > Yellow: > Accept no new TCP connections. > Reduce outgoing TCP windows. > Drop all sessions which have not passed > a packet in the last N seconds. > > Red: > Drop all un-assembled fragments. > Drop all "final-stages" TCP pcbs. (i.e. CLOSING, FIN_WAIT_1, FIN_WAIT_2 or TIME_WAIT) > Drop all sessions which have not passed > a packet in the last M seconds. (M << N) + Drop connections that are in SYN_RECEIVED state > Now, before anyone starts point indignated fingers in RFC's and > other such moral high-ground, let me just make it perfectly clear > that YELLOW isn't set until the system detects the risk of meltdown > and RED is the meltdown. Personally, if violating an RFC can keep my server from panicking when attacked, then the RFC can go take a hike (as I think I've already demonstrated with TCP_RESTRICT_RST and TCP_DROP_SYNFIN) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message