New firewall matcher - CONNECTION RATE

RouterOS General
1

The next RouterOS version will include a new exciting feature - matching connections by their speed. This will help you assign different rules for http downloads, in contrast to just surfing, find P2P downloads even if they mask themselves as HTTP, give priority to VOIP etc. See more here:

http://wiki.mikrotik.com/wiki/Connection_Rate

This setting is NOT YET AVAILABLE, it will become available with the next RouterOS release.

2

nice feature… maybe =)

btw,

connection-rate=200k-4294967295

looks a bit strange… maybe you should allow ‘connection-bytes’ syntax for ‘maximum’ value? so that it be

connection-rate=200k-0
3

Yes, this will be changed in the version after the next one

4

if it will work it gonna be ultimate wepon against rapidshare:)

5

if it won’t work - it gonna be funny :smiley:

6

question?


you say the next release it will be avalable

but next release is 3.29
and on the link you say it will be available from 3.30

so will there first be a beta or did you make a trying error
when can we expect the next release?

7

no, next release will be v.3.30

8

so what happend to 3.29



as i cant download is from the webpage? :laughing:

or is mikrotik skipping a version again?

9

v3.29 was released only to add support for RB750. v3.30 is on the web now

10

cool thats why we like mikrotik

11

Sounds like a great new feature.
I normally receive an email for each new FW update.
Didn’t see anything for 3.30?

12

like this:

:laughing:
500000-4294967295


add action=add-src-to-address-list address-list=high-udp-src address-list-timeout=50s chain=prerouting comment=“” connection-rate=500000-4294967295 disabled=no in-interface=LAN protocol=udp

13

Better try 500k-1000M. :slight_smile: will look much better :slight_smile:

14

This sounds like a great feature, it will be good to try it and get my head around the logic

15

This exciting feature was in patch-o-matic-ng repo since 2004, what took you so long ?

16

where? RouterOS is built by MikroTik from ground up, we use the vanilla kernel and that’s almost it.

17

so far everything from toturial works fine:) hehe beware rapidshare:)

can this be specifide to only port 80?

hehe i will check it in a sec:)

edit:

true it can work like it:)

18

im dont get what this does can somebody maybe explan this to me? :frowning:

19

its so easy my friend :slight_smile: for example someone is downloading large file from web (~100MB) and u dont want that he will use all the bandwith you have so if you set up this config from toturial on wiki you get something like this:
when he start download first 500KB goes with speed of non havy-conn but when this particular conn gets more then 500kb it is change to havy-conn so his speed will drop down. but when he open web page he won’t see the diffrence because this conn is lower then 500KB. Easy?


and there is also conn-rate(the topic). so when he even download large file but the source server have lower upload speed then the conn-rate parameter then this connection wont be change to havy-conn even if its 1GB

and also in QT when conn is mark as havy its get lower priority then non-havy

Am I right?
correct me if I’m wrong…

20

Example in that topic is quite simple, I’m thinking about 2 or 3 step limitation. First 500kB of conenction with one speed, then next 10MB with other speed, and then reset with even lower :slight_smile:. Really need to think about best implementation.

At this point - this is ideal solution for port 80 traffic, finally we can ensure that this port is used by HTTP mainly :slight_smile: