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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
