Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Dec 1998 12:05:28 -0500 (EST)
From:      Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM)
Message-ID:  <199812011705.MAA04251@khavrinen.lcs.mit.edu>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 1 Dec 1998 08:47:17 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812011705.MAA04251>