From: Michael Klinteberg <michael@klintan.cjb.net>
To: netfilter@lists.netfilter.org
Cc: Michael Klinteberg <micke@klintan.se>
Subject: Re: Please explain the limit match
Date: Mon, 2 Feb 2004 03:09:46 +0100 [thread overview]
Message-ID: <47445.4711344608$1075687922@news.gmane.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0402011643020.25106@localhost.localdomain>
On Sun, 1 Feb 2004 16:51:43 -0500 (EST)
"Robert P. J. Day" <rpjday@mindspring.com> wrote:
>
>
> On Sun, 1 Feb 2004, Michael Klinteberg wrote:
>
> > I have read the man page over and over again for the iptables limit
> > match. Don't quite understad the --limit and --limit-burst.
> >
> > Can anyone please give me some easy LOGing examples with diffrent
> > time-intervalls.
>
> i remember, once upon a time, trying to figure this out and becoming
> hopelessly confused by an overly-complicated explanation. once i
> discarded the verbiage, it seemed quite simple.
>
> think of starting with a collection of tokens that you use to pay
> for packets. if packets come in quickly, you'll quickly run out of
> tokens, and on a *regular* basis, you're given a token to replenish
> your supply.
>
> as an example, let's say you define a limit of 5/sec, and a limit
> burst of 10. this means (and please correct me if i'm wrong), you
> start with 10 tokens, and that's the *maximum* you'll ever be allowed
> to hold.
>
> every time a packet comes in that matches your criteria, if you want
> to
> accept it, you have to pay a token. based on your limit, you'll be
> replenished at the rate of 5/sec, or one every 0.2 seconds.
>
> if you get no packets, you'll just sit there, hoarding your 10
> tokens.
> if, suddenly, you get a flurry of activity (DoS attack), you'll spend
> your 10 tokens almost immediately, and then will have to reject
> further packets, except that every 0.2 seconds, you'll get another
> token, which you'll spend immediately as long as you have heavy
> incoming traffic.
>
> only when the traffic dies off will you get a breather and a chance
> to
> replenish your supply of tokens again, one every 0.2 seconds in your
> case. i did, in fact, test this with logging and it matches what i
> described here. others use an analogy of balls in a bucket, etc.
>
> rday
>
Thank you rday for your good explaining, it seems clearer now.
--
Michael K
next prev parent reply other threads:[~2004-02-02 2:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-01 21:12 Please explain the limit match Michael Klinteberg
2004-02-01 21:28 ` Alexis
2004-02-02 2:11 ` Michael Klinteberg
2004-02-01 21:51 ` Robert P. J. Day
2004-02-02 2:09 ` Michael Klinteberg [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-02-01 20:46 Michael Klinteberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='47445.4711344608$1075687922@news.gmane.org' \
--to=michael@klintan.cjb.net \
--cc=micke@klintan.se \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox