Sadly i have a bunch of customers with badly configured torrent clients, so they are overloading the sector with high number of packet/sec with low frame size.
(yes, we can tell them, they have no more download speed if they download by 10 streams or 100 streams - but the latter one highly degrades whole sector, even using NV2)
I don’t care what gentle users do, but i hate P2P traffic kills sector (with high pps and not high bandwidth) with bad configuration/stupid user.
I know, i can mark P2P packets, but it seems, i cannot limit it properly per user.
Any ideas would be welcome, especially a solution what can be installed on client CPE (mikrotik) what limits ~100pps in each direction (i can change for all traffic or only p2p).
Hello,
if you are using mikrotiks on client side, then configure these as routers and add simple queues.
so you will limit max throughput on client side. This is most effective solution.
Limit maximum upload speed to hinder sending traffic that would be otherwise thrown away when reaching where you normally limit bandwidth (i.e. pppoe server). Make sure you properly size queue type so you don’t create high latency.
Then for the specific answer to your question, use a firewall rule in forward chain with “limit” match to limit the packets per second. Look up “limit” in firewall filter wiki.
What you said is definitely bad - or my description was not too good: “with high pps and not high bandwidth”
I already limit the bandwidth, and i can do this on both router (not AP to keep free the AP’s cpu) and client side.
Keep in mind 2mbps (2048kbps) download can be 170pps with 1500byte frames what is nice - or it can be
500pps with 520byte frames what much worse.
What happens if the upload (128kbps = 16kbyte/s) at 1500byte frames - 10pps
if i see 200pps @ 128kbps upload cap that means around 100byte/s right?
So queue definitely NOT help in this, unless it can limit PPS, but currently it has no such feature.
I already have burst queues set to each user, and that limits both up and down. Queueing method used is “pfifo” with around 100packets in queue.
edit: also, i have setup a p2p matcher what limits TCP connections to max 100 on customer. Keep in mind, if torrent transmission is via UDP, it’s connectionless so not limited!
Try to research torrent client behavior with packet sniffer and you will see, that it receives data with large packetsize.
Connlimit isnt bad to limit connections but you wont get desired effect.
I’ve got a Queue tree set up with multiple 5 different levels, SIP, normal download, gaming, low priority download and P2P. I have a few different PCQ set up, download, download rest, upload, upload rest and P2P. The two primary have a limit of like 500 connections per IP, depending on whether a main router, AP, client, etc, but the download/upload rest is limited to 100-200 connections and P2P is limited to 10, sometimes less on equipment where the customer is a heavy P2P user.
It may not mark P2P traffic perfectly, but limiting the download rest PCQ connection seems to help cut back the number of connections a bit where the P2P markings miss.
That and you can limit the number of connections available to each CPE on non-standard ports.
Can you confirm that NV2 is affected badly, I would expect a small rise in latency but not so bad as to effect the user experience. TDMA should not allow a single node to take control of the AP like this
Well, this sector running NV2. Yes, small rise in latency - or even bigger latency in case of bigger tdma period (but that causes higher thruput as well). I think if one CPE is responsible for ~25% of packet/s on sector, that would affect others. I think, polling gives no equal “airtime” for CPEs.
