Linux Netfilter discussions
 help / color / mirror / Atom feed
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


  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