I just spent about 3 hours this morning trying to limit P2P using MT.

Now that most clients on our network seem to be using encryption none of the packet or connection marking is really making any difference.

I am using version 3.13.

Basically it all comes back to just plain bandwidth throttling and per client connection limiting.

Unless there is something I am missing.

Is Mikrotik really just falling behind on their P2P expertise?
Can I get another solution that will be able to handle most P2P even if it's encrypted, or are we just all dominated by encrypted P2P now regardless?

(can you tell I'm frustrated?)

My guess is not Mikrotik fault, although it's true that right now a lot of P2P can not be fully analised by MikroTik.
I have had some strange experience with packet mangle, like these:

1. I tried to limit Bittorrent using Layer7 Protocol and I saw that some of the connections where not
captured although that in the /ip firewall connections this connection was marked as established.
I consider this strange because torrents are using simple connections, easy to be captured I think.
2. I tried to capture some packets from Ares with zero result using again Layer7 protocol.
But this could be normal considering that Ares is using some kind of encrypted connection, at least
that's what I read about it.

So, I think softwares are using a lot of different ways to establish connections, it's not anymore simple port connection,
you see that port 80 is used by HTTP and Skype as well, Ares may be is using encrypted connections, etc.?

you cannot limit encrypted connections. but you may try to drop them. or you may limit all except known (http, ftp, etc)

I know this probably isn't the answer you want to hear, but limiting P2P, or any specific protocol or traffic is a never ending job. Bittorrent in particular can use random, encrypted ports, and in some cases plane old HTTP, so it's very difficult to match and throttle. In addition; from a moral standpoint I don't believe that limiting specific types of traffic is the *right* thing to do. People are paying for bandwidth and what they do with it is their right (until they break the TOS). What are your terms of service (TOS)? Do you tell your clients that you're going to limit P2P traffic, or other types of traffic? Many ISP's are under fire for concealing their P2P bandwidth throttling. I believe there may be some class-action lawsuits pending too against some big cable operators. Be very careful with how you implement this system, and what TOS you're clients have signed... you could be setting yourself up for a lawsuit.

With our network we take a 'if we don't hear about it, you don't hear about it' approach... e.g. if a user is downloading a ton of content and bogging down system, we have alerts that tell us that a hog is on the network. We then go to that user and try to up-sell a better connection, or depending on the circumstances, we may ask them to find a new provider. The same goes if we get a notice from the MPAA/RIAA, if we get a complaint, then the user will be suspended or disconnected.

There is a point in what you say webformix
but this isn't only about limiting or droping P2P, is also about QOS
If you can't divide the trafic into diferent services than you just can't
offer a Quality Of Service. In my point of view a P2P must have
the less priority in the traffic and all the rest should enjoy a higher priority.

can't you give known traffic high priority, and the other traffic - low?

Normis is right. There is now too much different traffic, I work in reverse, all traffic low priority unless told not to be. Obviously you can still try to block p2p anyway but I know it wont work fully. You see P2p programes are designed to get around ISP routers etc, they are maverick software

I think the problem usually seems not to be solved by priority anyway, as p2p is designed to get around that and normally it can use any port and opens so many connections can it seem to slow a shared connection even if not much bandwidth is being used.

The best option I have found is to use connection limit to suppress it and it works quite well.

For example between src ports 40000 - 65535 and dst ports 40000 - 65535 drop more than 2 tcp connections. This seems to stop it really being able to establish much links and seems to cause bittorrent etc to run very slow. Used in conjunction with p2p block and low priority seems to be quite good.

The best option I have found is to use connection limit to suppress it and it works quite well.

For example between src ports 40000 - 65535 and dst ports 40000 - 65535 drop more than 2 tcp connections. This seems to stop it really being able to establish much links and seems to cause bittorrent etc to run very slow. Used in conjunction with p2p block and low priority seems to be quite good.

spire2z ... is there any way i could see ur config on that ....??

i'm setting up a wisp/hotspot ... and trying to gather as much info and such to implement on the rb/1000 i am getting next week ... and p2p is one thing i need to control ... i'm on a vsat system with shared access already ...

thanks

He will simply lose clients that way. Internet is free information exchange. There is no filtering and never will be fully possible.

Solution is to simply aim to make web sites open FAST no matter what client is downloading and with how many connections.

Like Normis and Chupaka have said:

Simply mark http(s), then mark everything else as "everything". Give priority to http(s), consider bursts. Give lower priority to "everything".

Consider searching for methods to classify known protocols. One method is by v3.x Layer 7 - see MT WiKi. Other method is through incoming + outgoing port combination. There was a good list somewhere, maybe some firewall rules examples in the WiKi, don't remember.

Good Luck. Post your config after you're done refining it.

Hi ...

i'm on a small military base here in afghan ... i have a VSAT system that i use for my interent ... but i have lots of the soldiers that want in on it ... so .. i'm setting up wi-fi .. i have exclusive rights to do so ... on the FOB ...

but because the internet comes from a VSAT ... i can not have users using limewire .. etc . to hog the bandwidth ...
i already have 6TB of movies and music and such available on the internal LAN for ppl to watch or listen too ... so you see no need to hog the bandwidth ....

so yes i will limit p2p to nil .... if at all possible ... mostly ppl want access to myspace ... and skype ...

txs

can't you give known traffic high priority, and the other traffic - low?

I have difficulty implementing it that way.
If I want to max-limit each user to it assigned bandwidth, and at the same time limiting all known p2p traffic (in a single queue for that purpouse) that`s posible (at least to my limited skills).
But, I don`t know how to separate "interesting" traffic, priorize it with respect to "unknown" traffic and then limit each customer to its max bandwidth. (all of this using a single RB). That is how to join 2 queues and inject them in the per-customer queue.

Is there a way of doing it ?


Thanks,

Javier

It's impossible to limit speed of encrypted traffic (modern P2P). It has no pattern, or specific port, it is not possible to tell whether it's just some random data, or P2P.

It's impossible to limit speed of encrypted traffic (modern P2P). It has no pattern, or specific port, it is not possible to tell whether it's just some random data, or P2P.

i was looking at spire2z did ... i quoted him a few posts up ...

limit port connections ... from 40000-65000 to just 2 per client .... etc .. like that

uTorrent has no problem working on port 80, with encryption, it would look similar to SSL

Has there been any improvements to P2P detection in version 3.x from version 2.x of router os?

No need to stop p2p. Queues can and should ensure priority to icmp, dns, http(s), Skype, games... A Queue on your Public interface is meant for upload. You control which packets leave the router in what order, and which are dropped, therefore limiting the speed due to 'TCP window'.

Data received in our Public interface from our provider can be and should be classified, and speed-limited accordingly. This scheme will work with a slight delay, than classification being done at our ISPs end, in their routers, but works and ensures fair bandwidth distribution to our clients. The MikroTik router can and should classify and prioritize packets/flows coming in through the Public interface destined to our clients. This works because of TCP windowing capability. UDP traffic may decrease the efficiency of this, since it could bombard our Public interface. This happens when there is too much p2p activity?

Implement the Queues in your MikroTik. Test. see how the network performs when under big load. If you don't like it - try to limit speeds, rearrange priorities, etc. After this - if you still don't like it - try to drop and disallow p2p AS WELL AS consider upgrading your ISP link to ETHERNET - lowest delays, higher speeds, no p2p problems what-so-ever.

With some providers and link types important packets will move faster when the link is not being entirely used-up. Due to delay increasing when too much packers per second transferred, and so on.

Even our MikroTik router which we are trying to config to distribute speeds fairly, may suffer from 100% cpu usage, therefore forcing us to limit some traffic and free some resources to ensure low delay for important traffic.

MikoTik documentation is not enough for a new MikroTik honest customer to be able to do what he needs at first. The documentation and examples are not explained well. This is what is causing all this frustration seen on the forums.

Full Router configuration examples, optimized by top Network Professionals should be put up on the MikroTik WiKi, so that all of us can use them as they are - fully working, and therefore finally become satisfied honest customers.

If there are people willing to share their QoS + client bandwidth allocation ENTIRE configuration please write it in the WiKi - MikroTik gives free licenses for this.

Amen.

p.s. For starters, this method http://wiki.mikrotik.com/wiki/Queue_Tre ... interfaces must be combined with QoS: http://wiki.mikrotik.com/wiki/Mangle%2C ... lmost_done .

The documentation and wiki are fine for router administrators, remember this is a Router, not some graphics program for beginners. If you need help, you can ask our consultants, or here in the forum. If you have a specific issue, you can of course also ask the support.

The documentation and wiki are fine for router administrators, remember this is a Router, not some graphics program for beginners. If you need help, you can ask our consultants, or here in the forum. If you have a specific issue, you can of course also ask the support.

yes ... forum has been excellant source of ideas and such ... i'm a cisco guy ... but i'm switching to mikrotik because of the added features and benefits that i want and need ... i can not wait to get my rb/1000 in the mail .... and my 433ah with the 3 radios ...

only thing .. mail to here in afghan is slower than the slow boat to china ... hahahaha ....

1st - there are configuration examples on wiki. if you cannot read those - that is more your problem.

2nd - i haven't seen 2 similar routeros configuration, if they are not trivial any more, everyone have their needs and all of that reflects on configuration, so why waste time and make useless examples in the first place?

3rd - support will not configure router for you, but will help with solving some problems, point in right direction - all you have to do is read thoroughly manual, see wiki examples and confogure router that way.

4th - of course, consultant will make full configuration for your router for a fee.

5th - if you think that other users will benefit from what you know and what to help, you can create wiki article, and you could benefit from it yourself too.

2nd - i haven't seen 2 similar routeros configuration, if they are not trivial any more, everyone have their needs and all of that reflects on configuration, so why waste time and make useless examples in the first place?

i agree you on this point .... but posting examples do help newbies work through their unique situations ... give and help mature their ideas and approach to problem solving ... too "see" how one person was able to solve a problems ... opens ideas and approaches to solving other different ... but maybe similar problems ....

that is one of the purposes of this forum ...and why i choose mikrotik ... the exchange of ideas and approaches of problem solving ....

you cannot limit encrypted connections. but you may try to drop them. or you may limit all except known (http, ftp, etc)

Can somebody tell me how to do this in simple way?
I've already marked known traffic, but I can't find simple way to mark all other traffic. To add rule to mark all without mark.
Maybe I missed something.

you cannot limit encrypted connections. but you may try to drop them. or you may limit all except known (http, ftp, etc)

Can somebody tell me how to do this in simple way?
I've already marked known traffic, but I can't find simple way to mark all other traffic. To add rule to mark all without mark.
Maybe I missed something.

its exactly the way you just said. after mangle all known traffic create a mangle without any options and just with a packet mark (packetmark=other)

add chain=prerouting (or forwarding chain) action=mark-packet new-packet-mark=other_in passthrough=no comment="unmarked traffic" disabled=no

its exactly the way you just said. after mangle all known traffic create a mangle without any options and just with a packet mark (packetmark=other)

add chain=prerouting (or forwarding chain) action=mark-packet new-packet-mark=other_in passthrough=no comment="unmarked traffic" disabled=no

Well, I've tried. Not working.
If I have one rule for http and at the bottom one rule as you recommend without any option marking everything as p2p then most part of http traffic goes to queue for p2p, but if I disable rule marking p2p traffic - all http traffic goes to http queue:
ip firewall mangle pr
chain=forward action=mark-packet new-packet-mark=http
passthrough=yes connection-mark=http
chain=forward action=mark-packet new-packet-mark=p2p
passthrough=yes

queue simple prin
name="p2p" dst-address=0.0.0.0/0 interface=all parent=none
packet-marks=p2p direction=both priority=8
queue=hotspot-default/hotspot-default limit-at=0/0
max-limit=9000000/9000000 burst-limit=0/0 burst-threshold=0/0
burst-time=0s/0s total-queue=default-small
name="http" dst-address=0.0.0.0/0 interface=all parent=none
packet-marks=http direction=both priority=8
queue=default-small/default-small limit-at=0/0
max-limit=3000000/3000000 burst-limit=0/0 burst-threshold=0/0
burst-time=0s/0s total-queue=default-small

set passthrough=no to first rule

Thank you a lot.
I had a filling that I missed something
Everything works now.

It's impossible to limit speed of encrypted traffic (modern P2P). It has no pattern, or specific port, it is not possible to tell whether it's just some random data, or P2P.

So what you mean is, uTorrent encrypted traffic is not TCP, therefore TCP Window option will not work on it? What if our Internet Gateway is bombarded with this kind of IP traffic on the Local interface by a Client, what would the best practice be then?

Hey - we can still tell if it is with lower priority since it's not TCP. We could give protocol=!tcp priority=8 limit-at=0 max-limit=1M ?



I mean rally, p2p is a good thing, but Quality of Service and congestion control is even better. The two worlds should work together - for p2p to work and for .... http browsing to be fast on congested networks.

p.s. now that I think of it - uTorrent encrypted traffic probably has its own implementation of "windowing" to avoid flooding?

no, i didn't say that uTorrent traffic is not TCP.

I meant that you can't predict which port it will use, it chooses a port that is open.