Date: Wed, 13 Dec 2000 14:54:30 -0500 (EST) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: Mike Silbersack <silby@silby.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <Pine.BSF.4.21.0012131443470.816-100000@overlord.e-gerbil.net> In-Reply-To: <Pine.BSF.4.21.0012131325470.13447-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Dec 2000, Mike Silbersack wrote: > > I also see no compelling reason to put ICMP Timestamp > > in a seperate queue, but what I would recommend is seperate queues for > > ICMP messages which would be defined as "query/response" and those which > > would be called "error" messages. If someone needs more specific > > protection they can use dummynet. > > Well, I should make a clarification here. My use of the word queue is > wrong. All the rate limiting does is count packets per second and drop > those above the allowed amount. Hence, there's no significant overhead > to having counters for each seperate type. > > The main reason tstamp is distinct from echo is so that they can be > reported correctly. Given that they are distinctly different packets, I > think this makes sense. (And has less overhead than dummynet would.) Is there some specific reason you need timestamp seperate? If you're really up for that, why not just limit each ICMP type seperately? As for performance, this limiting occurs deeper in the stack then ipfw, and w/dummynet you have the flexability to mask the ips so that each interface or aliased ip could have a seperate rate limit as well. My thinking on the matter is that these limits should provide basic protection out of the box, and site specific limits should be done with dummynet. I personally agree with this patch because I think there should be seperate limits at some fundimental level, such as tcp-closed tcp-open udp(closed) icmp-response and icmp-error. How much further you want to push it is debatable mainly just because of the hastle of too many unnecessary tunables, not for any real performance or memory reasons. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012131443470.816-100000>