Community discussions

MikroTik App
 
wpeople
Member
Member
Topic Author
Posts: 358
Joined: Sat May 26, 2007 6:36 pm

High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 12:25 pm

Hello,

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).

Thanks guys!
 
zyzelis
Member Candidate
Member Candidate
Posts: 213
Joined: Sun Apr 08, 2012 9:25 pm

Re: High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 4:49 pm

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.
 
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Re: High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 7:35 pm

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.
Move along. Nothing to see here.
 
wpeople
Member
Member
Topic Author
Posts: 358
Joined: Sat May 26, 2007 6:36 pm

Re: High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 9:15 pm

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.
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.
 
wpeople
Member
Member
Topic Author
Posts: 358
Joined: Sat May 26, 2007 6:36 pm

Re: High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 9:18 pm

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.
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!
 
User avatar
CyberTod
Long time Member
Long time Member
Posts: 511
Joined: Wed Jan 25, 2012 10:23 am

Re: High number of packet/sec highly affects whole sector

Sun Nov 02, 2014 11:42 pm

Use a firewall rule with connection-limit
 
zyzelis
Member Candidate
Member Candidate
Posts: 213
Joined: Sun Apr 08, 2012 9:25 pm

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 10:26 am

What you said is definitely bad - or my description was not too good: "with high pps and not high bandwidth"
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.
 
wpeople
Member
Member
Topic Author
Posts: 358
Joined: Sat May 26, 2007 6:36 pm

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 3:19 pm

is there any known way to get desired effect?
 
zyzelis
Member Candidate
Member Candidate
Posts: 213
Joined: Sun Apr 08, 2012 9:25 pm

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 3:32 pm

is there any known way to get desired effect?
drop torrents at all?? :shock:

+1 i would to know
 
0ldman
Forum Guru
Forum Guru
Posts: 1447
Joined: Thu Jul 27, 2006 5:01 am

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 4:09 pm

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.
/
ip firewall filter

add chain=forward action=drop protocol=udp dst-port=!53 connection-limit=3,32 comment="UDP Conn Limit"

add chain=forward action=drop tcp-flags=syn protocol=tcp dst-port=1024-65535 connection-limit=10,32 comment="High Port Conn Limit"

add chain=forward action=drop tcp-flags=syn protocol=tcp dst-port=80 connection-limit=40,32 comment="Port 80 Conn Limit"

/
 
User avatar
karina
Member
Member
Posts: 448
Joined: Sat Feb 06, 2010 2:18 am
Location: Spain

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 4:27 pm

Hello,

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).

Thanks guys!
Hi,

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
 
wpeople
Member
Member
Topic Author
Posts: 358
Joined: Sat May 26, 2007 6:36 pm

Re: High number of packet/sec highly affects whole sector

Mon Nov 03, 2014 6:03 pm

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.

Who is online

Users browsing this forum: No registered users and 34 guests