Date: Mon, 24 Jan 2000 00:48:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Richard Steenbergen <ras@above.net>, Alfred Perlstein <bright@wintelcom.net>, freebsd-security@FreeBSD.ORG Subject: Re: stream.c Message-ID: <200001240848.AAA85106@apollo.backplane.com> References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net> <200001240738.XAA21595@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:}
:} The checksums are a pretty small amount of the CPU time burned. The RST
:} generation is by far the worst, the PCB hash lookups are 2nd after that.
:
:Any idea why RST generation is so bad?
Yes, there are several problems. First, if you are on a HUB you are
eating additional network bandwidth with the responses and also
potentially creating a severe collision problem. Second, the collision
problem can cause the output queue to back up, causing legitimate
connections to fail that would not have otherwrised failed. Third the
bogus RST's may cause ICMP bounces from wherever they are sent to,
resulting in even more input traffic. Fourth RST responses to certain
IP addresses, such as multicast or broadcast addresses, can cause
additional traffic. Fifth you increase (as in potentially double)
the interrupt load on your host due to the transmission of the RST's.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001240848.AAA85106>