LLQ required

Hi

i hope to see LLQ in the coming ROS6 .


Thanks

Strict prioritization is a must have feature.

Subscribing…

I agree, suscribe and hold hope!

Yes !!! We need this for voip !

I agree.

I dont caer about VOIP a lot, but I have a constant stream of financial data that goes over my network that has to have absoluet priority :wink:

This is a must-have! Subscribing.

+1 here :slight_smile:

Voice and “financial data” prioritisation can already be achieved, I suggest you to watch some presentations by Janis Megis:
http://www.tiktube.com/video/mJeK3iHGhLKLIKImpnCsFrHvnlIomlpG=

LLQ is just another feature, but you can do it already.

normis:
Can you answer, is it possible to make qos working with pcq?

And how “LLC” is possible?

If you can’t do it now in HTB (currently implemented), you most probably will not be able to do it in LLQ also. Both will have degree of complexity in configuration and acheiving goals

Both have very similar set of features, in one you can do some things easier than in other, but i don’t really see the need for wasting time and implement feature that is not necessary. Let MT work on multi-threading more - that is feature we really need, especially with upcoming CCR

I don’t have any visible error in my QoS configs. I checked it many times, rechecked it with others qos implementations, with mikrotik wiki, and etc etc.

Even Traffic Inspector on windows provides more useful (if not ideal) qos, but with bad throughput (no more than 1000 pps).

Most better way to check if qos working ideally - ping running at lower latencies with torrents running at max speed.
If ping goes nicely, then voice, games, dns requests will do the same for sure.

In our network there is many gamers, while their os or antivirus downloading updates - their online games becoming a slideshow.

It seems that it’s not only my problem.

Well, then you and others are doing something wrong. I have no such problems. it just take a little bit of magic in mangle with packet-marks - queues are simple afterwards.

Do you even read my post?

I don’t have any visible error in my QoS configs. I checked it many times, rechecked it with others qos implementations, with mikrotik wiki, and etc etc.

post your config please. it may look correct to you, but it may be in fact wrong.

My current config (I've cut it for better reading):

jan/06/1970 05:42:18 by RouterOS 5.20

/queue tree
add max-limit=9400k name=bandwidth-control parent=global-out
add limit-at=8M max-limit=9400k name=users-down parent=bandwidth-control
add limit-at=1400k max-limit=9400k name=users-up parent=bandwidth-control
add max-limit=9400k name=qos-total packet-mark="" parent=global-in
add limit-at=8M max-limit=9400k name=qos-down parent=qos-total
add limit-at=1400k max-limit=9400k name=qos-up parent=qos-total
add limit-at=2M max-limit=9400k name=qos-http-down packet-mark=qos-http-down parent=qos-down priority=2
add max-limit=9400k name=qos-other-down packet-mark=qos-other-down parent=qos-down
add limit-at=256k max-limit=9400k name=qos-http-up packet-mark=qos-http-up parent=qos-up priority=2
add max-limit=9400k name=qos-other-up packet-mark=qos-other-up parent=qos-up
add limit-at=1M max-limit=9400k name=qos-cs16-down packet-mark=qos-cs16-down parent=qos-down priority=1
add limit-at=1M max-limit=9400k name=qos-cs16-up packet-mark=qos-cs16-up parent=qos-up priority=1
/queue type
set 0 pfifo-limit=45
add kind=pcq name=pcq-unlim256-down pcq-burst-time=5s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=512k pcq-src-address6-mask=64
add kind=pcq name=pcq-unlim256-up pcq-burst-time=5s pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-limit=30 pcq-rate=192k pcq-src-address6-mask=64
add kind=pcq name=pcq-unlim512-down pcq-burst-time=5s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=1024k pcq-src-address6-mask=64
add kind=pcq name=pcq-unlim512-up pcq-burst-time=5s pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=256k pcq-src-address6-mask=64
add kind=pcq name=pcq-workers-down pcq-burst-time=4s pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-limit=30 pcq-rate=4M pcq-src-address6-mask=64 pcq-total-limit=1000
add kind=pcq name=pcq-workers-up pcq-burst-time=4s pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-limit=30 pcq-rate=6M pcq-src-address6-mask=64 pcq-total-limit=1000
add kind=pcq name=pcq-unlim1024-up pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=512k pcq-src-address6-mask=64
add kind=pcq name=pcq-unlim1024-down pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2048k pcq-src-address6-mask=64
/queue tree
add max-limit=9400k name=unlim256-down packet-mark=unlim256_traffic_down parent=users-down queue=pcq-unlim256-down
add max-limit=9400k name=unlim512-down packet-mark=unlim512_traffic_down parent=users-down queue=pcq-unlim512-down
add max-limit=9400k name=workers-down packet-mark=workers_traffic_down parent=users-down queue=pcq-workers-down
add max-limit=9400k name=unlim256-up packet-mark=unlim256_traffic_up parent=users-up queue=pcq-unlim256-up
add max-limit=9400k name=unlim512-up packet-mark=unlim512_traffic_up parent=users-up queue=pcq-unlim512-up
add max-limit=9400k name=workers-up packet-mark=workers_traffic_up parent=users-up queue=pcq-workers-up
add max-limit=9400k name=unlim1024-down packet-mark=unlim1024-traffic-down parent=users-down queue=pcq-unlim1024-down
add max-limit=9400k name=unlim1024-up packet-mark=unlim1024-traffic-up parent=users-up queue=pcq-unlim1024-up
/ip firewall address-list
add address=00.00.49.233 comment="{-5BAD-4C96-BC65-}" list=unlim1024_clients
add address=00.00.49.132 comment="{-7387-4EDC-928B-}" list=unlim256_clients
add address=00.00.49.148 comment="{-C3CC-4FEA-BDE2-}" list=unlim256_clients
add address=00.00.49.147 comment="{-52AD-4139-9758-}" list=unlim256_clients
add address=00.00.49.199 comment="{-A7C0-4C09-A870-}" list=unlim512_clients
add address=00.00.49.20 comment="{-BD9D-4BE5-8E14-}" list=unlim256_clients
add address=00.00.49.186 comment="{-CCDD-4C5E-83D1-}" list=unlim256_clients
add address=00.00.49.37 comment="{-455C-490F-9992-}" list=unlim256_clients
add address=00.00.49.26 comment="{-7B2B-4678-B26F-}" list=workers_clients
add address=00.00.49.134 comment="{-7B82-4E33-A612-}" list=unlim256_clients
add address=00.00.49.188 comment="{-46B3-4A1A-933F-}" list=unlim256_clients
/ip firewall filter
add chain=input protocol=icmp
add chain=input connection-state=established in-interface=WAN
add chain=input connection-state=related in-interface=WAN
add chain=forward comment="Authorize users" out-interface=WAN src-address-list=unlim256_clients
add chain=forward out-interface=WAN src-address-list=unlim512_clients
add chain=forward out-interface=WAN src-address-list=unlim1024_clients
add chain=forward out-interface=WAN src-address-list=workers_clients
add action=drop chain=forward out-interface=WAN
add chain=forward dst-address-list=unlim256_clients in-interface=WAN
add chain=forward dst-address-list=unlim512_clients in-interface=WAN
add chain=forward dst-address-list=unlim1024_clients in-interface=WAN
add chain=forward dst-address-list=workers_clients in-interface=WAN
add action=drop chain=forward in-interface=WAN
add action=drop chain=input comment="Block all another traffic from internet" in-interface=WAN
/ip firewall mangle
add action=mark-packet chain=forward comment=unlim256 dst-address-list=unlim256_clients in-interface=WAN new-packet-mark=unlim256_traffic_down out-interface=LAN passthrough=no src-address-list=!local_subnet
add action=mark-packet chain=forward dst-address-list=!local_subnet in-interface=LAN new-packet-mark=unlim256_traffic_up out-interface=WAN passthrough=no src-address-list=unlim256_clients
add action=mark-packet chain=forward comment=unlim512 dst-address-list=unlim512_clients in-interface=WAN new-packet-mark=unlim512_traffic_down out-interface=LAN passthrough=no src-address-list=!local_subnet
add action=mark-packet chain=forward dst-address-list=!local_subnet in-interface=LAN new-packet-mark=unlim512_traffic_up out-interface=WAN passthrough=no src-address-list=unlim512_clients
add action=mark-packet chain=forward comment=unlim1024 dst-address-list=unlim1024_clients in-interface=WAN new-packet-mark=unlim1024-traffic-down out-interface=LAN passthrough=no src-address-list=!local_subnet
add action=mark-packet chain=forward dst-address-list=!local_subnet in-interface=LAN new-packet-mark=unlim1024-traffic-up out-interface=WAN passthrough=no src-address-list=unlim1024_clients
add action=mark-packet chain=forward comment=workers dst-address-list=workers_clients in-interface=WAN new-packet-mark=workers_traffic_down out-interface=LAN passthrough=no src-address-list=!local_subnet
add action=mark-packet chain=forward dst-address-list=!local_subnet in-interface=LAN new-packet-mark=workers_traffic_up out-interface=WAN passthrough=no src-address-list=workers_clients
add action=mark-packet chain=prerouting comment=QoS-HTTP dst-address-list=local_subnet in-interface=WAN new-packet-mark=qos-http-down passthrough=no protocol=tcp src-address-list=!local_subnet src-port=80
add action=mark-packet chain=prerouting dst-address-list=!local_subnet dst-port=80 in-interface=LAN new-packet-mark=qos-http-up passthrough=no protocol=tcp src-address-list=local_subnet
add action=mark-packet chain=prerouting comment=QoS-CS1.6 dst-address-list=local_subnet in-interface=WAN new-packet-mark=qos-cs16-down passthrough=no protocol=tcp src-address-list=!local_subnet src-port=27000-27150
add action=mark-packet chain=prerouting dst-address-list=!local_subnet dst-port=27000-27150 in-interface=LAN new-packet-mark=qos-cs16-up passthrough=no protocol=tcp src-address-list=local_subnet
add action=mark-packet chain=prerouting comment=QoS-Other dst-address-list=local_subnet in-interface=WAN new-packet-mark=qos-other-down passthrough=no src-address-list=!local_subnet
add action=mark-packet chain=prerouting dst-address-list=!local_subnet in-interface=LAN new-packet-mark=qos-other-up passthrough=no src-address-list=local_subnetWhat can I say... I've posted similiar configs on the forum, and no one found any problems.
Using this config http packets can't take over the torrents even if http's limit-at is high and its priority is highest.

Is the silence a proof that my config correct?

I think, no. Not at all.

I have not fully analyzed the config snippet you’ve posted since it’s quite time-consuming task, but I do think there’s something I should point you at.

From the snippet you’ve posted it is not cleat what local_subnet address list is. I assume that all entries of the unlim256_clients, unlim512_clients, unlim1024_clients and workers_clients address lists belong to the local_subnet as well. Please correct me if I’m wrong.

Then as far as I understand any packet can be marked with only a single packet mark at a time, so any time you mark the packet with a new packet mark the previous packet mark gets lost.

Now looking at the Packet Flow Diagram you can see that Mangle Prerouting happens before Mangle Forward and thus all your ‘qos-*’ packet marks get overwritten in Mangle Forward. And specifying ‘passthrough=no’ in one chain does not make any difference for the rules from another chain.

Yes, all these clients belong to the local_subnet.

Then as far as I understand any packet can be marked with only a single packet mark at a time, so any time you mark the packet with a new packet mark the previous packet mark gets lost.

Why do you think that the previous packet mark gets lost? I don’t get your point, please explain.

Mangle Forward and thus all your > ‘qos-*’ > packet marks get overwritten in Mangle Forward.

By what? Why?

And specifying ‘passthrough=no’ in one chain does not make any difference for the rules from another chain.

I don’t understand your point there either. passthrough=no used to ignore all next mangle rules for this marked packets in a current chain.

That’s how it works. I did not find it documented anywhere, so I found it out by experiment. As soon as you mark a packet with a new packet mark, previous packet mark (if any) gets discarded.

Lets take, for example, the 0.0.49.20 IP address from your config. It falls into the unlim256_clients address list as well as into the local_subnet address list. When packet from 0.0.49.20 to (say) 1.2.3.4 port 80/tcp passes you router it first gets into the prerouting mangle chain, hits the rule

add action=mark-packet chain=prerouting comment=QoS-HTTP dst-address-list=local_subnet in-interface=WAN new-packet-mark=qos-http-down passthrough=no protocol=tcp src-address-list=!local_subnet src-port=80

at which point the qos-http-down packet mark is assigned to the packet. But while being further processed by the router the packet then gets into the forward mangle chain, where it hits the following rule

add action=mark-packet chain=forward comment=unlim256 dst-address-list=unlim256_clients in-interface=WAN new-packet-mark=unlim256_traffic_down out-interface=LAN passthrough=no src-address-list=!local_subnet

and at this point the unlim256_traffic_down is assigned to the packet while the previous packet mark (qos-http-down) is discarded.

First packets gets caught by mangle prerouting, ‘passthrough=no’ sends packet directly to HTB, where it get prioritizes in global-in queue. Next ‘shaped unmarked packets’ gets caught by mangle forward (or postrouting), after that it goes into HTB where they get shaped according to user bandwidth limit in the global-out queue.

After shaping these packets will not being qos’ed, because qos queues is in global-in, as packet flow diagram says it isn’t after global-out for sure.