One of the most common issues that organizations who don't have a lot of bandwidth deal with is WAN over-utilization. Either an organization isn't in an area where faster broadband or fiber connectivity is available, the cost of fiber is out of reach, or there are just too many users trying to use a finite resource. This affects the entire organization, slowing down email and web use, voice and video conferences, etc. In the worst cases one or two people are using up the entire organization's bandwidth with P2P applications like BitTorrent, or by streaming high-def video while everyone else struggles to understand why everything over the WAN is so slow. We have a handy fix for P2P downloads as well when you're done with this article, if that is something affecting your organization.

 This isn't hard to fix at all, in fact it's fairly easy. Using Mikrotik Queues can allow us to put bandwidth limitations in place, and also ensure a (relatively) fair distribution of bandwidth between all users. We can also give priority to one network's bandwidth usage over another's if we wanted to. We'll do this by using Mikrotik PCQ - PCQ standing for "Per Connection Queue". Using a PCQ instead of another type of queue allows for even distributions of bandwidth per connection. That means that one person on a subnet gets just as much bandwidth when they open a webpage as someone else does. Other types of queues are available, but we won't cover them in this article.

For this article we're just using one Mikrotik router, with a LAN subnet of 192.168.1.0/24 that all 200 users are sitting on. I'm not creating a topology diagram for this article because there's just one router and one subnet. We have one WAN connection, Ether3, and it's connected to a 50Mb/sec broadband line. Users have been complaining that the Internet is always slow, and every now and then we've seen someone who is using 10Mb or 15Mb/sec on their own just watching videos.

First, we'll flag the download traffic using a Mangle rule to mark the packets as they come in from the WAN and head to the LAN. We have to mark the packets first so the PCQ knows what packets to impose limits on. The mangle rule is shown below:

/ip firewall mangle add action=mark-packet chain=forward comment="192.168.1.0/24 Download" dst-address=192.168.1.0/24 in-interface=ether3 new-packet-mark="192.168.1.0/24 Download"

The packet counter should be incrementing for this rule if traffic is flowing and the rule was set up correctly. This rule will mark all packets coming in interface Ether3 with a destination address in the 192.168.1.0/24. Once the packets have been marked then we can apply a PCQ to them. The PCQ is shown below:

/queue type add kind=pcq name="192.168.1.0/24 Download" pcq-dst-address6-mask=64 pcq-limit=300 pcq-rate=5M pcq-src-address6-mask=64 pcq-total-limit=40M

 A few fields in the PCQ deserve explanation. Each connection that is matched to this PCQ gets its own little queue, and the quantity of those little queues can be set by you. Increasing them takes up more RAM and CPU time, but not having enough of them means that packets could get bottlenecked in the queue and dropped - it's a balancing act and some tuning may be required. In this case I have 200 users, so I'm going to limit the amount of those little queues to 300, which admittedly is an educated guess. The PCQ Rate is the most amount of bandwidth that an individual connection can use. This is a user streaming Pandora, or loading a web page, or watching a streaming video. The PCQ Total Limit is the total amount of bandwidth that all the connections can use at once. We have a 50Mb/sec line, so I'm limiting total connections to 40Mb/sec and giving myself a little wiggle room for other traffic. This all relies on the fact that not all 200 of our users are going to be using their allotted 5Mb/sec at once. 

Finally we'll add the PCQ set up earlier to the Queue Tree. This is where the rubber meets to the road, and the PCQ we created actually gets applied to the packets we're marking:

/queue tree add comment="192.168.1.0/24 Download" name="192.168.1.0/24 Download" packet-mark="192.168.1.0/24 Download" parent=global queue="192.168.1.0/24 Download"

That's it, everything is in place! Here is what an iperf bandwidth test looked like prior to the PCQ being put in place:

The first transfer is an upload, the second is the download, both sitting squarely around 120Mb/sec. Now here's what it looks like with the PCQ in place:

With the PCQ in place it's a very different story, with bandwidth being limited to 4.89Mb/sec on average. Multiple iperf tests running in parallel show the same thing as well. Please note: If you're going to implement bandwidth throttling some tuning will be necessary. You may need to tweak one setting or multiple settings to make sure that everyone gets their share of bandwidth, without being overly restrictive. Good luck!