We've found ways to block it, but is there a way to just limit the throughput on torrents (P2P)?? We don't want to totally kill the service, would have a lot of unhappy customers, but for those that just abuse it downloading/uploading 24/7, is there way to just limit the bandwidth for P2P??? We already use PCQ's for traffic shaping, I'd like to say keep someone at 7mb, but limit torrents to 1mb.

Thanks for any help!

Below is how you could create a PCQ for equal access along with limits. This limits P2P tgo 768k download & 64k upload for the entire network and allows 128k/64k for each user. You'll probably want to adjust the target interface along with the speeds to better fit your use case. This is a very heavy handed limit which may be a bit aggressive.

It is also worth noting that this will not catch all P2P traffic types but it is still very helpful.

We used to use simple queues, but they didn't work well. We use PCQ's to limit the download/upload on our customers. I'm not sure how your method would work for limiting only P2P?

We know how the PCQ's work, as far as adding a simple queue, how does it only limit P2P by naming the queue P2P? I remember back on the 5.xx firmware there was an option when adding a simple queue for limit P2P, but now with 6.XX there's only "Packet marks" and no other options..

Wow, that is embarrassing... I hope I didn't mess you up and cause you to limit your entire network to those slow speeds... Your absolutely right, calling it P2P is not enough to match P2P traffic.

I copied this from a disabled rule that was working before the RouterOS version 6 upgrade... The simple queue used to have a P2P matcher, now it appears that you will have to add a packet mark match using a mangle rule and match the mark it in the queue.

As far as if simple queues work... I had this rule working on a router (PowerRouter 732) passing 250Mbps download a peek time with over 2000 customers behind it. The big disadvantage of Simple queues is that the packet has to be checked against every queue to see if it matches... with HTB matching its faster and asynchronous (or at least not sequentially parsed).

You could have a rule in your prerouting and postrouting on your internet interface (in and out) that matches new connections that match the P2P matcher and marks the connection. Then mark all packets that are part of a P2P connection with something like P2P_Packet.

Then create a simple queue or a HTB tree queue to limit the speed of that connection.

After that then the info I posted previously will work with the addition of a mark matcher: "packet-marks=P2P_Packet"

I hope this is a better answer then my first answer.

No, I know better than to add a queue without an IP address

I didn't even try it. I'll try to figure out what your saying and test it later. Basically I just want to limit the speed of all P2P connections. We have a Mikrotik at each tower now, broke them all out so there's only a few hundred queues at each routerboard now. PCQ's do a MUCH better job at traffic shaping than using a simple queue for each customer! We had mass problems, say we set someone at 7 Down / 3 Up, they'd only see around 5.5mb on speedtest. PCQ 7 Down 3 Up and they get 100% right on the speed we set for them!

This was my only queue on the edge router. We do have speed queues on the local routers that are simple queues as well but they match on the interface (we are using PPPoE). If you going to try running this on the same router that your using to limit speed to customers then your going to need to double queue (queue on ingress and egress). We also had performance issues on higher speed connections but this was due to only having a 10 packet buffer with the default-small queue type. After changing to a 50 packet buffer we didn't have issues. If you have issues implementing things then let me know. I'd be happy to do a screen sharing with you to help you get this implemented.

Thanks. We just changed out our core Cisco 7200 with a Mikrotik CCR and it seems to be doing well, it handles about 600mb of traffic at night. I do see CPU spikes up to 80-100% once in a while, for no known reason. It usually sits around 5% maybe, then BAM, 80-100% for about 10-15 minutes. Someone said it could be BGP updating.

We don't use PPoE. It would be nice to figure out how to limit P2P bandwidth though, I'd rather just test it out on a couple smaller routers first, not sure if I want to do anything at the core. I might not want to do this with EVERYONE, it would even be nicer if I could limit P2P on just one customer, that is abusing it.

I would be surprised if BGP is doing that to you unless your dropping and re-establishing the full routing table. I am supposing that your checking the log & interface stats to see if your having interface issues. Check the status tab under the BGP peer. I have received just under 6 million updates over 22 days for an average of 268,329 per day which is pretty close to receiving 50% of my prefix count daily in updates... if you have a info that is way out of line with that then maybe you do have a BGP issue going on. I am seeing that I receive between 250k and 350k per day of uptime on each of my bgp relationships that are communication a full routing table. I don't know for sure that this is a sane measurement of the health of routing updates but its something anyway.

It would be interesting to watch the "profile" and see where the cpu is being utilized.

You could match connections that have transfers a large amount of traffic over P2P and add them to an address list. If your passing 600Mbps + through a single router you probably would be better moving the P2P queue to distribution routers or to local routers so that your not having to deal with so many packets per second on the rule.