From owner-freebsd-current Tue Dec 1 09:06:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18081 for freebsd-current-outgoing; Tue, 1 Dec 1998 09:06:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18073 for ; Tue, 1 Dec 1998 09:06:34 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id MAA04251; Tue, 1 Dec 1998 12:05:28 -0500 (EST) (envelope-from wollman) Date: Tue, 1 Dec 1998 12:05:28 -0500 (EST) From: Garrett Wollman Message-Id: <199812011705.MAA04251@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM) In-Reply-To: <199812011647.IAA07545@apollo.backplane.com> References: <005b01be1cf6$e6368da0$6cb611cb@saruman.scitec.com.au> <199812010708.XAA03688@apollo.backplane.com> <199812011619.LAA04055@khavrinen.lcs.mit.edu> <199812011647.IAA07545@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > :You can check net.inet.ip.intr_queue_drops to see whether this is in > :fact happening. > You asked for it :-) > shell15.ba.best.com net.inet.ip.intr_queue_drops: 3028088 > shell17.ba.best.com net.inet.ip.intr_queue_drops: 1066352 I'd say you were getting some serious livelock here... (Or else the machines were too busy servicing other, non-network, interrupts which took precedence.) > ARP's reasonably rate-limited because most subnets are /24's, it's > the packets queued up waiting for the ARP to resolve that are the > problem. That doesn't limit the rate, that only limits the number of machines which might potentially be annoyed by an ARP storm. However, in looking at the code, we do effectively rate-limit our ARPs, contrary to what I thought; the ARP code will refuse to send more than five broadcasts in 20 seconds (per destination). This doesn't help me all that much (I have twelve /16s), but is probably good enough for most users. > An etherswitch has an internal packet buffer. If the buffer fills up the > switch will generate a collision on packets being received to try to > slow down the transmitters (by forcing backoff/retry) while the packet > buffer drains. Well, maybe your vendor's products violate the standard in this way. I always connect network-intensive devices at full-duplex, so the only back-pressure comes from 802.3x PAUSE frames (yeah, right). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message