On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> Is there some specific reason you need timestamp seperate? If you're
> really up for that, why not just limit each ICMP type seperately?
There's no real need for it to be separate, it just feels cleaner. I
prefer seeing the two cases have separately reported values. (Have I
missed any icmp types that a host could respond with? If so, please tell
me so that I can add them.)
> 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.
Hm, true. I was thinking of limiting the outgoing side, which would mean
ipfw comes later in the string, but I suppose that if you limit on the
incoming ipfw's sooner.
> 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.
I wasn't planning to subdivide the reporting any more in future patches,
so you shouldn't see any new tunables popping up for that reason.
Mike "Silby" Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
