I have been trying to get something working properly with Queues but seem to be unable to achieve the desired goal without limiting throughput to a lower level all the time.

I have satellite uplink with traffic policers on the circuit that drop everything exceeds 5Mbps. The problem I'm having is getting queuing to limit the traffic below 5Mbps without having it constantly exceed 5Mbps on the interface. All traffic is being accounted for but the queue shows a lower level then the actual interface. I setup traffic monitoring to alert me if it exceeds 5Mbps. Currently the only way I can keep it from exceeding the limit is to limit it 2.8Mbps or so. It's an dedicated PTP satellite connection for delivering Internet service. I have tried many combinations trying to get the queue to catch and properly manage all the traffic have failed. I have every possible IP accounted for in the rule that is catching the traffic. I also have a few public IP addresses that I removed from the post. They account for all the IP addresses used across this connection. Does someone already have an example using PCQ that properly limits upload?

Had the wrong rule posted before. This is the 5Mbps upload side.
/queue simple comment="Whole Network Traffic Queue" limit-at=384k/0 max-limit=2400k/250M name=EVERYONE queue="DOWNLOAD IP/default-small" target=10.0.0.0/8,63.140.126.68/30,63.140.126.72/30,63.140.126.80/28,172.16.0.0/12,192.168.0.0/16


add kind=pcq name="DOWNLOAD PORTS" pcq-classifier=dst-address,dst-port pcq-dst-address-mask=24 pcq-limit=30KiB pcq-total-limit=50000KiB.. Each class C is a different customer.

I have been trying a variety of ways to try and get it to properly enforce the upload with no success yet.

Thanks,

- Dan

If you take a look at https://wiki.mikrotik.com/wiki/Manual:Queue, you'll notice that there are two ways to limit/shape traffic: "simple queue" & queue tree.
With simple queues one needs to define limits for all targets. With queue tree, usually attached to interface one needs to account for all classes (=packet marks).

Both methods have their constraints which needs to be respected for proper functioning. If you provide more info on your particular configuration, someone will be able to help you, I'm sure.

Hello and thanks for your reply.

I am using simple queues for this process. As they can be added and stacked pretty easily. I need to use PCQ queues and at the same time limit maximum traffic to 5 Mbps. Seems pretty simple right? It's not, MIkrotik will not properly enforce the 5Mbps limit. I hired a Mikrotik Specialist to review this setup just for this one issue. He said that it was not possible to keep it under the 5Mbps cap. In actual testing this seems to be the case. It will not record all trafffic on the Interface in the queue. The Interface will exceed the queue and exceed 5Mbps even thought it's set at 2400k as seen above in the rule. It still pushed over 5Mbps with that rule. I have already tried extremes such as marking ALL traffic going out the Interface thinking that it was somehow missing some of the trafffic. No dice, The PCQ queue does not limit trafffic and in fact allows it to push up over 5Mbps.

The rule I posted is the last queue before hitting the Interface directly. I have other simple queues per user that use this queue as the parent. I would be impressed if anyone has a queue rules will actually limit it to 5Mbps with PCQ, as it doesn't seem possible at the moment.

Am I using the wrong method to attempt this? If anyone has a working config that limits max traffic with PCQ, I Would love to see your config. The only other queues use the one above as a parent.

i.e.
add max-limit=2M/10M name="xxxx" parent=EVERYONE queue="default-small/DOWNLOAD PORTS" target=10.10.1.0/24
This is a PCQ for a single customer that has a class C. The rule feeds to the other as a parent. PCQ inside of PCQ works great with the desired results of providing even amount of shared bandwidth to users. I am just not to keep it from exceeding 5,000,000 bps.

Thanks,

- Dan

No dice, The PCQ queue does not limit trafffic and in fact allows it to push up over 5Mbps.

Are you sure that every single subnet in the parent target list is also the target of at least one child queue, and that child queue also has max-limit set for up and down?

If you create a single simple queue to limit, say, 192.168.111.0/24 to 5M up and down, and if you have two computers in the 192.168.111.0/24 range on 192.168.111.2 and 192.168.111.3 they will both be limited correctly to a total of 5Mbps up and down for their combined usage.

However if you add a child queue to that parent for only one of those two computers, 192.168.111.2, and limit it to 2M up and down, that will now be the only computer limited and 192.168.111.3 will be completely unlimited (even though the parent covers the entire range and the child queue falls within this IP range). The limits in the parent queue will no longer apply if the packet matches the parent but no children, or if it does match a child but that child is set to unlimited. That traffic will not even be counted under the parent anymore.

The way people generally avoid this is by creating a catch-all simple queue as the last child queue (largest ID #) under the parent queue, with target set to all of the targets covered by the parent and max-limit set to the same max limits as the parent. This catch all child simple queue will only be used if no children before will match, since the child queues are processed in ascending order of ID number.

Also, the queue type setting for the parent will not have any effect if the parent has children. It looks like you have a PCQ queue set on the parent, which won't do anything. If you wish to use PCQ it has to be set on the child queues, not the parent.

I don't agree with below, else what is the use of using PCQ?

Also, the queue type setting for the parent will not have any effect if the parent has children. It looks like you have a PCQ queue set on the parent, which won't do anything. If you wish to use PCQ it has to be set on the child queues, not the parent

Due to lack of info supplied, I suspect the the issue the OP is experiencing is by not configuring the rates on the queue types:

I have at a client the below and works 100%:

I have at a client the below and works 100%:

Code: Select all

/queue simple
add comment="1Mb" max-limit=50M/50M name=ParentQ queue=pcq-uload-1M/pcq-dload-1M target=172.16.0.0/16
/queue type
add kind=pcq name=pcq-uload-1M pcq-classifier=src-address pcq-rate=1024k
add kind=pcq name=pcq-dload-1M pcq-classifier=dst-address pcq-rate=1024k

I did test it myself before I replied originally. I do not see any child queues in your example above, so of course that would work. That is a different scenario than the original poster's.

The Child Q's are created dynamically

The Child Q's are created dynamically

Through what feature - DHCP? Hotspot? PPP? Can you execute "/queue simple print" and show the output? Printing the list will include all dynamic queues as separate items.

The Child Q's are created dynamically

Through what feature - DHCP? Hotspot? PPP? Can you execute "/queue simple print" and show the output? Printing the list will include all dynamic queues as separate items.

Through "Simple Queues". Printing only shows the parent Q, see below screenshot.

Through "Simple Queues". Printing only shows the parent Q, see below screenshot.
PCQ-Child-Qs.JPG

Those are not child queues. Those are PCQ queues. The OP has actual manually created simple queues as child queues that have parent set, so the simple queues list appears as a tree structure. His PCQ in the parent will not work because he has manually created children for different subnets and applied different settings for them. Yours is working because yours does not have child queues (PCQ queues are like children but are not children).

Agree, at time of typing my previous post, I thought that there might be a misunderstanding between us.

The setup used is outlined below. A queue for each customer (PCQ)/24, A catchall queue(s) for each major subnet, The parent PCQ queue.

Each customer has their own /24 private IP assignment with a route that only forwards that traffic. 10.10.1-254.x/24, 176.16.x.x/24, or 192.168.x.x/24. I would like each customer to have their own PCQ to give a queue to each session. This works well in regard to the user uploading and downloading and running a ping with consistent results for all three. Then I have bandwidth limit of 5Mbps upload that I cannot exceed that i need all of them to get a slice of.

The customer queue (this queue only shapes UPLOAD):
add burst-limit=2M/0 burst-threshold=256k/0 burst-time=15s/0s limit-at=200k/0 max-limit=1200k/10M name="" packet-marks=no-mark parent=EVERYONE queue=UPLOAD_PORTS/default-small target=10.10.1.0/24

This is the catchall queue for that subnet:
add limit-at=200k/0 max-limit=2M/10M name=Catchall10 parent=EVERYONE queue=UPLOAD_PORTS/default-small target=10.0.0.0/8
add limit-at=200k/0 max-limit=2M/10M name=Catchall172 packet-marks=no-mark parent=EVERYONE queue=UPLOAD_PORTS/default-small target=172.16.0.0/12
add limit-at=200k/0 max-limit=2M/10M name=UserCatchall192 packet-marks=no-mark parent=EVERYONE queue=UPLOAD_PORTS/default-small target=192.168.0.0/16


The customer rule is first in the list then the catchall and then the parent is at the bottom.
add limit-at=200k/0 max-limit=2M/10M name=CatchallMAIN packet-marks=no-mark parent=EVERYONE queue=UPLOAD_IP/default-small target=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16


Queue types:
add kind=pcq name=UPLOAD_IP pcq-classifier=src-address pcq-rate=200k pcq-src-address-mask=24 pcq-total-limit=40000KiB
add kind=pcq name="DOWNLOAD PORTS" pcq-classifier=dst-address,dst-port pcq-limit=30KiB pcq-total-limit=50000KiB

I have tried disabling the individual and the catchall rules and just have the single PCQ parent with similar results. It exceed 5Mbps when set at 2400K.

The only thing you don't see is a few additional Public IP addresses. There are a couple of small /29 subnets. I also thought about the whole group of subnets being treated as one given the /24 mask on the PCQ. I would have to create different queue type, but this isn't necessary as those addresses are not allocated to users.

I you have a single PCQ rule that can be tried I will give it a shot. I haven't found a way to keep it from exceeding 5Mbps on the upload.

I do have another queue but it's accept marked traffic that is marked with mangle with DSCP of 62 since it's cached HTTP traffic. It doesn't get counted with the other network traffic.

Thank You, I appreciate any advice you can provide.

- Dan

I have tried disabling the individual and the catchall rules and just have the single PCQ parent with similar results. It exceed 5Mbps when set at 2400K.

You have a logic error somewhere where some traffic is not going into any of those queues. You have not accounted for all of your traffic somehow, and some traffic is not being matched by any queues. It is hard to tell where you have a logic error from only seeing slices of the simple queue config. It may be the public subnets you mention or a side effect of the web caching rule or something else.

Try disabling all of your queues and create a single simple queue without pcq like your current whole network queue:

/queue simple comment="Whole Network Traffic Queue" limit-at=384k/0 max-limit=2400k/250M name=EVERYONE queue="default-small/default-small" target=10.0.0.0/8,63.140.126.68/30,63.140.126.72/30,63.140.126.80/28,172.16.0.0/12,192.168.0.0/16

If you create that with all other simple queues disabled and the upload still goes up to 5Mbps, then the problem is that you have missed a target subnet. I'm assuming that you have FastTrack disabled as well, at least hopefully you do. With fasttrack enabled you would not catch a lot of traffic in the queues.

With simple queues in a parent/child relationship like this to do QoS for a connection it can be very easy to miss something. Limiting the total upload to 5M is possible, contrary to what the MikroTik consultant may have told you.

I went ahead and make a users address list on both sides of the circuit. I then dropped all traffic not destined for or from those addresses. Using torch I was able to confirm that only those specific addresses are going through now. I went ahead and disabled all the rules and modified the main queue with default-small/default-small. It works better but still blows past the set level. I have the queue set at 4400k and currently the queue shows it's throughput at 5.2Mbps.. That is the queue reporting that throughput. A straight plain jane queue is being completely overrun. All cached traffic is being marked so it cannot enter the queue. I have a queue at the top to graph that traffic. It does work more effectively than the PCQ as I had to set it to 1400k at one point to keep it from going over 5Mbps.
.
add action=drop chain=forward out-interface=ether1 src-address-list=!USERS
add action=drop chain=output out-interface=ether1 src-address-list=!USERS

The list has the public subnets plus these:
add address=172.16.240.0/20 list=USERS
add address=192.168.240.0/20 list=USERS
add address=10.10.0.0/16 list=USERS

The queue is set to 4400k, reporting 4900k throughput, the Interface is reporting 5Mbps. While this is being Torched and only the specific subnets are going through. Torch shows the full throughput as well. I'm lowing it to 4m as 4400k is going over 5Mbps too often.

add comment="Whole Network Traffic Queue" limit-at=384k/0 max-limit=4M/250M name=EVERYONE packet-marks=no-mark target=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 Plus the public subnets
It's weird, when set to default-small the export doesn't even list the queue-type. I'm assuming that must be the default.

So is there no way to limit the traffic effectively with PCQ?
I am only using the one queue at the moment. I though using default-small would cause unwanted packet loss, I ran a ping during the testing and didn't lose one of 3k packets. With max latency of 633 which is great (satellite). This is going through the infrastructure on the remote site also.

I went ahead and make a users address list on both sides of the circuit. I then dropped all traffic not destined for or from those addresses. Using torch I was able to confirm that only those specific addresses are going through now. I went ahead and disabled all the rules and modified the main queue with default-small/default-small. It works better but still blows past the set level. I have the queue set at 4400k and currently the queue shows it's throughput at 5.2Mbps.. That is the queue reporting that throughput. A straight plain jane queue is being completely overrun. All cached traffic is being marked so it cannot enter the queue. I have a queue at the top to graph that traffic. It does work more effectively than the PCQ as I had to set it to 1400k at one point to keep it from going over 5Mbps.
.
add action=drop chain=forward out-interface=ether1 src-address-list=!USERS
add action=drop chain=output out-interface=ether1 src-address-list=!USERS

The list has the public subnets plus these:
add address=172.16.240.0/20 list=USERS
add address=192.168.240.0/20 list=USERS
add address=10.10.0.0/16 list=USERS

The queue is set to 4400k, reporting 4900k throughput, the Interface is reporting 5Mbps. While this is being Torched and only the specific subnets are going through. Torch shows the full throughput as well. I'm lowing it to 4m as 4400k is going over 5Mbps too often.

add comment="Whole Network Traffic Queue" limit-at=384k/0 max-limit=4M/250M name=EVERYONE packet-marks=no-mark target=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 Plus the public subnets
It's weird, when set to default-small the export doesn't even list the queue-type. I'm assuming that must be the default.

So is there no way to limit the traffic effectively with PCQ?
I am only using the one queue at the moment. I though using default-small would cause unwanted packet loss, I ran a ping during the testing and didn't lose one of 3k packets. With max latency of 633 which is great (satellite). This is going through the infrastructure on the remote site also.

Yes of course this will also work with PCQ, but first things first, you need to figure out where the problem is. If you find that the amount going through the queue is still consistently less than the amount going out the interface then you might still have something else wrong. Either a target is missing, or you have packets that actually have a mark that are going across the link, and are not getting matched by the "no-mark" option. How are you marking the cached packets? Maybe there is a logic error there.

The queue might show a different value than the interface due to the timing that winbox updates the display, the packets going through the queue vs the interface might show a different number at the same time. As long the amount going out the interface is not consistently higher than the amount going through the queue it is not a problem.

One thing I am worried about however is traffic from the router itself. This might be the reason for the difference in rates between simple queue and interface, because packets being created by the router and going through the output chain probably will not be handled by the simple queue. You might be forced to use a combination of queue trees and simple queues.

Try creating a queue tree with similar parameters to the simple queue on the WAN interface and see if it matches all traffic and limits properly. If it does, the router itself is responsible for the remaining traffic, and you would need to use a mix of the two queue types to solve your problem.