We deal with this by using either SFQ or, preferably, Procera. SFQ is free,
works pretty well in most cases.
------ Original message------From: Kade Sullivan via AfDate: Mon, Oct 13, 2014
2:18 PMTo: [email protected];Subject:Re: [AFMUG] How to deal with constant customer
internet saturation.Thanks so much, Adam. I been thinking about how to
accomplish this all day. Just wasnt sure how to code it, and your suggestion
is basically identical to what I was envisioning.
On Mon, Oct 13, 2014 at 4:16 PM, Adam Moffett via Af <[email protected]> wrote:
Since it's on the forefront of my mind now, I just went ahead and added a
"tiny-download" packet mark for connections that moved less than 1 million
bytes. tiny-download gets priority 6 in the queue tree. Something like 20% of
traffic seems to fit that description.
I think I'll keep it.
Have you tried PCQ with lower priority on connections that have moved more
data? See below. That's saying any connection that has moved less than
50,000,000 bytes gets priority 7, while any connection moving more than that
gets the default priority 8.
Before I did this, if I ran a torrent at my house I would get a crummy speed
test and people in the house would complain about web pages being slow. After
doing this, the first thing I did was start up a torrent and let it run for
awhile, then do a speed test. You could see the throughput in uTorrent drop
while the speedtest went full throttle. So email and light web browsing (and
speed tests) can hum along while a torrent or video stream is hosing the
connection. I'm running this at the router at the tower by the way.
It's something like this:
/ip firewall mangle
add action=mark-connection chain=prerouting new-connection-mark=
tcp-connection protocol=tcp
add action=mark-packet chain=prerouting comment=short connection-bytes=
0-50000000 connection-mark=tcp-connection new-packet-mark=short-download
passthrough=no protocol=tcp
add action=mark-packet chain=prerouting comment=long connection-mark=
tcp-connection new-packet-mark=long-download passthrough=no protocol=tcp
add action=mark-packet chain=prerouting comment="short udp" connection-bytes=
0-50000000 new-packet-mark=short-download passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment="long udp" new-packet-mark=
long-download passthrough=no protocol=udp
/queue type
add kind=pcq name="PCQ short Download" pcq-classifier=src-address,dst-address
pcq-dst-address6-mask=64 pcq-limit=5k pcq-src-address6-mask=64
pcq-total-limit=40000
add kind=pcq name="PCQ long download" pcq-classifier=src-address,dst-address
pcq-dst-address6-mask=64 pcq-src-address6-mask=64 pcq-total-limit=40000
/queue tree
add name=queue1 parent=global queue=default
add name=queue8 packet-mark=short-download parent=queue1 priority=7 queue="PCQ
short Download"
add name=queue9 packet-mark=long-download parent=queue1 queue="PCQ long
download"
I believe in the definition of the PCQ queue type you could also limit the
speed of each connection.
A Torrent client could still hose this.....I'm not normally trying to get more
than one torrent at a time, so for my house it works great, but if you have
lots of torrents running and they each open many connections, it could take
quite awhile before the individual connections move enough data to hit 50meg.
I was thinking I would alter it with 3 or four stages of connection length with
gradually decreasing priority levels. I just haven't gotten around to it.
So it's becoming a reoccurring nightmare for me. I get a customer calling in
saying their internet is slow. It ends up being their upstream or downstream
or both are totally maxed out for hours on end. Unfortunately, my
responsibility does not stop there.
We have been going the route of installing Mikrotik's in the customer home,
which helps us identify the problem. But what do we do from there?
I feel like the overall bandwidth isnt the ENTIRE problem. With more
intelligent usage, more people can use it simultaneously. Of course, giving
them more speed would help, but I feel like it's a bandaid around the big
picture, which is the fact that nothing plays nice with anything else.
Are there any mikrotik guru's here that could figure something out that we
could preload on all these mikrotik routers that would help minimize this issue?
In my mind, I feel like the solution lies in the prioritization of each
connection, without putting a hard limit on any one device. I just can't seem
to figure out the proper implementation.
Are any of you seeing this reoccurring nightmare?
