Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, Im confused about the limit module. Please take a look down quoted on netfilter.org
Quote:
limit
This module must be explicitly specified with `-m limit' or `--match limit'. It is used to restrict the rate of matches, such as for suppressing log messages. It will only match a given number of times per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments:
--limit
followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using `/second', `/minute', `/hour' or `/day', or parts of them (so `5/second' is the same as `5/s').
--limit-burst
followed by a number, indicating the maximum burst before the above limit kicks in.
This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters:
# iptables -A FORWARD -m limit -j LOG
The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged; back where we started.
Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3.
So the example here is no paremeter given in limit so it will take the default right? --limit 3/hour and --limit-burst 5 and it will refresh 1 per 20 minutes if no packets hits the rule.
Now on the below statement it said that only 5 connection will be log so it means its the limit-burst. Why is it not 8? Because the limit is 3? Is it mean that the number on limit is useless? Please enlighten me also refer this question on the statement below the command. Thanks!
Think of it as a bucket of tokens. The limit-burst is the size of the bucket, in this case 5 tokens. The "--limit 3/hour" is the rate at which new tokens get added to the bucket as long as it is not full. Each successful match removes one token from the bucket.
Think of it as a bucket of tokens. The limit-burst is the size of the bucket, in this case 5 tokens. The "--limit 3/hour" is the rate at which new tokens get added to the bucket as long as it is not full. Each successful match removes one token from the bucket.
So meaning if you get a match of 4 in an hour there will be 1 token left right? But if you get a match of 5 in an hour the bucket will be empty (no tokens left) and no packet will match that rule until tokens will refresh right? Then how can I calculate the amount of time for every token to refresh?
Since you don't know when those 3/hour ticks are coming along, you can't know it exactly. The feature isn't intended for precise measurements. I looked around for some way to see the current state of that bucket, but couldn't find anything.
Since you don't know when those 3/hour ticks are coming along, you can't know it exactly. The feature isn't intended for precise measurements. I looked around for some way to see the current state of that bucket, but couldn't find anything.
Okay, thanks. For final thought the limit-burst is the hard limit. If number of packet that match reach the limit burst within hour/sec/min it will not accept anymore until the tokens will regenerate. That is my final thought. I'm getting it right and clear?
Yes. Of course the bucket does not have fill completely, just be non-empty. For the given example (3/hour), a new token will arrive every 20 minutes. As soon as that occurs, another packet could satisfy the match, which would again empty the bucket. In 20 more minutes, another token will be added to the bucket. The bucket can never hold more than 5 tokens (--limit-burst 5).
Yes. Of course the bucket does not have fill completely, just be non-empty. For the given example (3/hour), a new token will arrive every 20 minutes. As soon as that occurs, another packet could satisfy the match, which would again empty the bucket. In 20 more minutes, another token will be added to the bucket. The bucket can never hold more than 5 tokens (--limit-burst 5).
Yeah!Now I clearly got it. Thanks to you Btw, what if the limit is higher than limit burst? For example, limit 50/sec limit-burst 20 what would happen?
Yeah!Now I clearly got it. Thanks to you Btw, what if the limit is higher than limit burst? For example, limit 50/sec limit-burst 20 what would happen?
In theory you could match 20 packets in the first millisecond and thereafter be limited to one packet every 20 milliseconds (1/50 second), but I don't know how that mechanism is actually implemented. Somehow I doubt that something gets scheduled every 20 milliseconds to refill the bucket asynchronously. Implementation details matter when you start pushing to extremes, and that's getting beyond what I know or care about just now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.