Hello,

Could you please someone explain to me how the dst-limit works exactly in the firewall rules? I have looked at the wiki and the 1 example available that I found in the forums, as well as my own attempts and I still can't figure out.

What I want is this:
I want to limit the rate at which hotspot users can send email via Yahoo. I want it to be 10/ hour and I want it to be a rolling average (as opposed to counting to 10 and blocking for a period of time). If the rolling average is more than 10/hour, the actual packet is dropped and if it is less than 10/hour, the actual packet is accepted. (I have a reliable indicator content that I watch for in the packets ... that tells me that an email is being sent ... blocking that one packet will disrupt the communication and the email is not sent)

My specific questions are the following ... and please excuse if they are silly ... I really tried hard to research this information without luck:

1, What does setting the rate to 10/h means? Packets that otherwise match the filter rule are counted and the count is divided by the time elapsed between the last and first packet .. and when that is over 10/h, the action is triggered?
2, I know that the burst means that the first X number of packets are not counted, which will mean that the action is triggered regardless of the rate for the first X packets
3, What is expire? Is that the expiration of the individual counts in point #1 above? The only sensible setting I see here should match my rate interval (1 hour), otherwise my rolling average will not be accurate-

The one thing I know is that the dst-limit doesn't work as I described above, so please someone help me clear this up.

The examples in this forum all rely on point #2 above. They get their filter rule triggered based on the number of burst packets and then after the Xth packet, they mark the source or destination and start blocking further traffic ...

If you also have suggestions how to achieve my original goal, please also let me know … I’m sure that it will benefit a lot of people.

Thanks
GL

well ... it seems like that nobody knows exacly how dst-limit works? ...

I was able to figure out partly why it doesn't seem to work. The expire time units seem to be off. Counted packets expire quickly. Someone mentioned in the forums that the time units are actually 1/10th seconds.

However I still don't know the point of the time unit in the rate variable. Since I can expire individual counts with a custom time interval, only the number of counts still existing in memory should matter. Having 2 different time intervals just confuses things - since we don't know which takes precedence over the other... especially if one or both are implemented wrong.

GL

However I still don't know the point of the time unit in the rate variable.

This is probably to simplify rate calculations for long time periods.
The rule with 'dst-limit' is true and action is triggered when packet rate is below rate set by you.
In opposition to 'connection-limit' when action i triggered when packet rate is above limit.

Someone mentioned in the forums that the time units are actually 1/10th seconds.

AFAIK this was never explained by MT, so maybe it's time to do this

Here is a link to 'dst-limit' example by Chupaka:
http://forum.mikrotik.com/viewtopic.php ... 7&p=278189

HTH,

Thanks.

I have seen this example. The problem is that that is mostly a count and drop scenario. For a well written dst-limit you should not need the mark and drop part, just the dst-limit with a return or accept action and then a simple drop afterward. That way you have drops based on the actual rate and not just Y minutes drop after the first X packets.

GL

not just Y minutes drop after the first X packets

IMHO you misunderstood 'expire' parameter of 'dst-limit'.
Meaning of this parameter is: after which time are idle entries expired from hashtable?
Hashtable tracks every connection as set by 'Limit By' parameter (in Winbox).
Set 'expire' time to 1 hour, limit by: 'src. and dst. addresses' and 'dst-limit' should works as you want.
Let me know how it works.

HTH,

We agree on the function of the expire parameter.

What is the point of setting a 10/hour rate if I expire my entries after say 5 minutes? And conversely what is the point in setting the expire to be longer than the time rate unit parameter.

The first scenario makes the true rate 10/5 minutes, while the second has a 10/hour rate, but is potentially wasting resources... so as far I can tell the time unit in the rate has no use.

But for example the "simple" limit has no expire .. parameter? How are those entries made to expire?

Geza

The first scenario makes the true rate 10/5 minutes

IMHO in this case rate is 0.167 packets/min or in other words 0.00278 packets/sec, with expire time of 5 min.

And conversely what is the point in setting the expire to be longer than the time rate unit parameter.

What's wrong with rate=100 packets/min and expiry=10 min?
Traffic for this specific connection, defined by 'Limit By' in hashtable can exists for few hours.
When this traffic stops, hash and its counters are removed from hashtable after 10 min, that's all.
'Expire' timer starts when connection becomes idle, not when connection starts.
Hashtables don't waste much resources, so if you want expire=1 hour, just set this value.

HTH,

There is a difference between 10/5 minutes and 2/1 minute (ie: 5 minute rolling average vs 1 minute rolling average)

but I understand your thinking ... Set a true rate in the rate section like 2/minute and set expiration to 5 minutes will make it 10/5 minutes ... but it would be nice to get a confirmation from MT.

Other than that, this is completely redundant and misleading. All they would need to ask for is a number and an expiration. If I want 10/5 minutes or 2/1 minute. I can set the count to 10 or 2 and set the expiration to 5 minutes or 1 minute.

Setting the rate to 1/s and the expiration to 1ms for example has no meaning. It will only catch rates over 1/ms (since expired entries are not part of the average) .. so the 1/s part is misleading. In other situation people thinking that 1/s rate with a 1h expiration will allow them to catch a burst of DOS, but it won't because that will allow exactly 3600 packets/connections to come in within 1 second if during the previous hour none came in.

GL

In other situation people thinking that 1/s rate with a 1h expiration will allow them to catch a burst of DOS, but it won't because that will allow exactly 3600 packets/connections to come in within 1 second if during the previous hour none came in.

'Rate' and 'expire' are two separate things.
Packet rate is internally calculated, probably in 'per second' basis, and according to your 'rate' settings 'action' is triggered or not with every packet checked.
'Expire' has no meaning if connection is active, if it becomes idle is removed from hashtable after 'expire' time.
When your connection defined by 'Limit By' starts again, after 'expire' time, packet rate calculation starts from begining because counters were removed from hashtable.
When connection starts again during 'expire' time, counters with some values belonging to this hash are used.

but it would be nice to get a confirmation from MT.

MT guys, where are you???

HTH,

I think you have the same question as I.

How is the rate calculated? You assume that it is based on a per second basis and expiry doesn't affect statistics.

I assume that it is calculated over the whole hash table (number_of_active_connections + number_of_not_expired_but_inactive_connections)/(time_oldest-time_youngest) ... so expiry does affect the statistics and it is a rolling average.

There are 2 interpretations of the rate in the 2nd option. It could be the rate as defined in the rule like 5/s ... but my opinion is that it is way too restrictive. It should be that the (active + not_expired_but_inactive) connections must be less than the number value in the rate field. That way creatively adjusting the expiry value could get you any connection rate you want.

From a programmer standpoint I can see counting connections in the hash table and generating average values from readily available data looks like a more probable implementation as opposed an undefined method if internal counting

GL

Hi,

ROS is based on Linux kernel and I found some information in 'iptables' manual.

'dst-limit' behaves exactly like 'limit'.

and

'limit' - this module matches at a limited rate using a token bucket filter.

TBF is a fixed rate filter, and it matches underlimit packets and doesn't match overlimit packets.
Packet rate is not calculated in any way, we both were wrong.

HTH,