We will help up to a point, then we just give them the unrealistic option to buy a fortigate from us that they can pay us to manage or they can manage themselves. The fortigate cloud reporting is slick because it will give them granualar detailed reports on the who what when and where of their bandwidth useg. Our contracted services customers love the reports, especially when its LDP into the active directory so they know what users are doing what and when. Screw making it our problem.
On Mon, Oct 13, 2014 at 3:33 PM, Adam Moffett via Af <[email protected]> wrote: > > 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? >> >> > -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925
