Manual:HTB: Difference between revisions

From MikroTik Wiki
Jump to navigation Jump to search
← Older edit
Megis (talk | contribs)
470 edits
No edit summary
Reinisjs (talk | contribs)
290 edits
No edit summary
 
(54 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Versions|2.9, v3, v4}}
==Theory==
==Theory==


===Structure===
===Structure===
Hierarchical Token Bucket (HTB) allows to create hierarchical queue structure and determine relations between parent and child queues and relation between child queues. As soon as queue have at least one child it become a parent queue. All child queues (don't matter how many levels of parents they have) are treated as they were on the same (bottom) level of HTB. Child queues make actual traffic consumption, parent queues are responsible only for traffic distribution. Child queues are not able to get more traffic than parent has.
 
HTB (Hierarchical Token Bucket) is a classful queuing method that is useful for handling different kind of traffic. We have to follow three basic steps to create HTB:
 
* '''Match and mark traffic''' – classify traffic for further use. Consists of one or more matching parameters to select packets for the specific class.
* '''Create rules (policy) to mark traffic''' – put specific traffic class into specific queue and to define the actions that are taken for each class.
* '''Attach policy for specific interface(-s)''' – append policy for all interfaces (global-in, global-out or global-total), for specific interface or for specific parent queue.
 
HTB allows to create a hierarchical queue structure and determine relations between queues, like "parent-child" or "child-child".
 
As soon as queue has at least one child it becomes a '''inner''' queue, all queues without children -  '''leaf''' queues. '''Leaf''' queues make actual traffic consumption, '''Inner''' queues are responsible only for traffic distribution. All '''leaf''' queues are treated on equal basis.


In RouterOS it is necessary to specify '''parent''' option to assign queue as a child to other queue
In RouterOS it is necessary to specify '''parent''' option to assign queue as a child to other queue


===Dual Limitation===
===Dual Limitation===
Each queue in HTB have two rate limits:
Each queue in HTB has two rate limits:
* '''CIR''' (Committed Information Rate) – ('''limit-at''' in RouterOS) worst case scenario, flow will get this amount of traffic no matter what (assuming we can actually send so much data)
* '''CIR''' (Committed Information Rate) – ('''limit-at''' in RouterOS) worst case scenario, flow will get this amount of traffic no matter what (assuming we can actually send so much data)
* '''MIR''' (Maximal Information Rate) – ('''max-limit''' in RouterOS) best case scenario, rate that flow can get up to, if there is spare bandwidth
* '''MIR''' (Maximal Information Rate) – ('''max-limit''' in RouterOS) best case scenario, rate that flow can get up to, if there queue's parent has spare bandwidth


In other words, at first  '''limit-at''' ('''CIR''') of the all queues will be satisfied, only then child queues will try to borrow the necessary data rate from their parents in
order to reach their '''max-limit''' ('''MIR''').


In another words, at first HTB will try to satisfy every child queue's '''limit-at''' ('''CIR''') only then it will try to reach '''max-limit''' ('''MIR''')
Note: '''CIR''' will be assigned to the corresponding queue no matter what. (even if max-limit of the parent is exceeded)  


To ensure optimal (as designed) usage of dual limitation feature we suggest to stick to these rules:
That is why, to ensure optimal (as designed) usage of dual limitation feature, we suggest to stick to these rules:
* Sum of committed rates of all children must be less or equal to amount of traffic that is available to parent.  
* Sum of committed rates of all children must be less or equal to amount of traffic that is available to parent.  
::''CIR(parent)* ≥ CIR(child1) +...+ CIR(childN)''  
::''CIR(parent)* ≥ CIR(child1) +...+ CIR(childN)''  
::: '' *in case if parent is main parent CIR(parent)=MIR(parent)''
::: '' *in case if parent is main parent CIR(parent)=MIR(parent)''
* Maximal rate of any child must be less or equal to maximal rate of the parent
* Maximal rate of any child must be less or equal to maximal rate of the parent
::''MIR (parent) ≥ MIR(child1) & MIR (parent) ≥ MIR(child2) & MIR (parent) ≥ MIR(childN) ''
::''MIR (parent) ≥ MIR(child1) & MIR (parent) ≥ MIR(child2) & ... & MIR (parent) ≥ MIR(childN) ''
 
 
Queue colors in Winbox:
* 0% - 50% available traffic used - green
* 51% - 75% available traffic used - yellow
* 76% - 100% available traffic used - red


===Priority===
===Priority===


Priority is used for creation of the strict order - who will get traffic first. Queue with higher priority will reach its '''limit-at''' before the queue with lower priority and after all '''limit-at'''s are satisfied queue with higher priority will reach its MIR before the queue with lower priority. 8 is the lowest priority, 1 is the highest.
We already know that '''limit-at''' ('''CIR''') to all queues will be given out no matter what.  


Priority is responsible for distribution of remaining parent queues traffic to child queues so that they are able to reach '''max-limit'''
Queue with higher priority will reach its '''max-limit''' before the queue with lower priority. 8 is the lowest priority, 1 is the highest.
Make a note that priority only works:
Make a note that priority only works:
*  for child queues - as soon as you assign at least one child to the queue, priority option will have no meaning in this queue
*  for '''leaf''' queues - priority in '''inner''' queue have no meaning.
*  if '''limit-at''' and/or '''max-limit''' is specified (not 0)
*  if '''max-limit''' is specified (not 0)
 
== Examples==
 
In this section we will analyze HTB in action. To do that we will take one HTB structure and will try to cover all the possible situations and features, by changing the amount of incoming traffic that HTB have to recycle. and changing some options.
 
 
===Structure===
 
Our HTB structure will consist of 5 queues:
* '''Queue01''' inner queue with two children - '''Queue02''' and '''Queue03'''
* '''Queue02''' inner queue with two children - '''Queue04''' and '''Queue05'''
* '''Queue03''' leaf queue
* '''Queue04''' leaf queue
* '''Queue05''' leaf queue
 
'''Queue03''', '''Queue04''' and '''Queue05''' are clients who require 10Mbps all the time
Outgoing interface is able to handle 10Mbps of traffic.
 
===Example 1 : Usual case===


[[Image:HTB_Example1.png|Structure|600px]]


* '''Queue01''' limit-at=0Mbps  max-limit=10Mbps
* '''Queue02''' limit-at=4Mbps  max-limit=10Mbps
* '''Queue03''' limit-at=6Mbps  max-limit=10Mbps priority=1
* '''Queue04''' limit-at=2Mbps  max-limit=10Mbps priority=3
* '''Queue05''' limit-at=2Mbps  max-limit=10Mbps priority=5


== Example==
===Result of Example 1===


In this section we will analyze HTB in action. To do so we will take one specific example of HTB in one specific moment in time, when HTB have to recycle specific amount of incoming traffic.
* '''Queue03''' will receive 6Mbps
* '''Queue04''' will receive 2Mbps
* '''Queue05''' will receive 2Mbps
* '''Clarification:''' HTB was build in a way, that, by satisfying all '''limit-at'''s, main queue no longer have throughput to distribute


===Structure===
===Example 2 : Usual case with max-limit===
 
[[Image:HTB_Example2.png|Structure|600px]]
 
* '''Queue01''' limit-at=0Mbps  max-limit=10Mbps
* '''Queue02''' limit-at=4Mbps  max-limit=10Mbps
* '''Queue03''' limit-at=2Mbps  max-limit=10Mbps priority=3
* '''Queue04''' limit-at=2Mbps  max-limit=10Mbps priority=1
* '''Queue05''' limit-at=2Mbps  max-limit=10Mbps priority=5
 
===Result of Example 2===
 
* '''Queue03''' will receive 2Mbps
* '''Queue04''' will receive 6Mbps
* '''Queue05''' will receive 2Mbps
* '''Clarification:''' After satisfying all '''limit-at'''s HTB will give throughput to queue with highest priority.
 
===Example 3 : Inner queue limit-at===
 
[[Image:HTB_Example3.png|Structure|600px]]
 
* '''Queue01''' limit-at=0Mbps  max-limit=10Mbps
* '''Queue02''' limit-at=8Mbps  max-limit=10Mbps
* '''Queue03''' limit-at=2Mbps  max-limit=10Mbps priority=1
* '''Queue04''' limit-at=2Mbps  max-limit=10Mbps priority=3
* '''Queue05''' limit-at=2Mbps  max-limit=10Mbps priority=5
 
===Result of Example 3===
 
* '''Queue03''' will receive 2Mbps
* '''Queue04''' will receive 6Mbps
* '''Queue05''' will receive 2Mbps
* '''Clarification:''' After satisfying all '''limit-at'''s HTB will give throughput to queue with highest priority. But in this case '''inner''' queue  '''Queue02''' had  '''limit-at''' specified, by doing so, it reserved 8Mbps of throughput for queues  '''Queue04''' and '''Queue05'''. From these two '''Queue04''' have highest priority, that is why it gets additional throughput.
 
===Example 4 : Leaf queue limit-at===
 
[[Image:HTB_Example4.png|Structure|600px]]
 
* '''Queue01''' limit-at=0Mbps  max-limit=10Mbps
* '''Queue02''' limit-at=4Mbps  max-limit=10Mbps
* '''Queue03''' limit-at=6Mbps  max-limit=10Mbps priority=1
* '''Queue04''' limit-at=2Mbps  max-limit=10Mbps priority=3
* '''Queue05''' limit-at=12Mbps  max-limit=15Mbps priority=5
 
===Result of Example 4===
 
* '''Queue03''' will receive ~3Mbps
* '''Queue04''' will receive ~1Mbps
* '''Queue05''' will receive ~6Mbps
* '''Clarification:''' Only by satisfying all '''limit-at'''s HTB was forced to allocate 20Mbps - 6Mbps to '''Queue03''', 2Mbps to '''Queue04''', 12Mbps to '''Queue05''', but our output interface is able to handle 10Mbps. As output interface queue is usually FIFO throughput allocation will keep ratio  6:2:12 or 3:1:6
 
 
 
==HTB configuration example==
 
Assume that  we want to limit maximum download speed for subnet 10.1.1.0/24 to 2Mbps and distribute this amount of traffic between the server and workstations using HTB (limit upload to 2Mbps). Since HTB works in one direction and is implemented on outbound interface,  HTB for download will be on ether2 and HTB for upload will be on ether1. 
 
<center>[[Image:image8008.gif]]</center>
 
 
<center>[[Image:image8009.gif]]</center>
 
 
 
The first, we need to classify traffic.
 
Mark traffic form/to server. The first rule we will mark the outgoing connection from server and with the second one, all packets, which belong to this connection (download and upload packets for this connection):
 
 
<pre>
/ip firewall mangle> add chain=prerouting src-address=10.1.1.1/32 action=mark-connection \
new-connection-mark=server_con
 
/ip firewall mangle> add chain=forward connection-mark=server_con action=mark-packet  \
new-packet-mark=server
</pre>
 
 
Do the same for workstation too. Match all workstation connections, mark it with the same mark (new-connection-mark=workstation_con) and after that mark all packets which belong to these workstation.
 
 
<pre>
/ip firewall mangle> add chain=prerouting src-address=10.1.1.2
action=mark-connection new-connection-mark=workstation_con
/ip firewall mangle> add chain=prerouting src-address=10.1.1.3
action=mark-connection new-connection-mark=workstation_con
/ip firewall mangle> add chain=prerouting src-address=10.1.1.4
action=mark-connection new-connection-mark=workstation_con
 
/ip firewall mangle> add chain='''forward''' connection-mark=workstation_con  action=mark-packet \
new-packet-mark=workstations
</pre>
 


[[Image:HTB_structure.png|thumb|Structure|500px]]
At the end create '''/queue tree''' for upload and download based on figure 8.8 and figure 8.9.


Our HTB structure will consist of 14 queues:
Queue tree for upload limitation is implemented on '''''ether1''''' interface.
* '''Queue01''' has two childs - '''Queue02''' and '''Queue08'''
* '''Queue02''' has two childs - '''Queue03''' and '''Queue07'''
* '''Queue03''' has three childs - '''Queue04''', '''Queue05''' and '''Queue06'''
* '''Queue04''' child
* '''Queue05''' child
* '''Queue06''' child
* '''Queue07''' child
* '''Queue08''' has two childs - '''Queue09''' and '''Queue12'''
* '''Queue09''' has two childs - '''Queue10''' and '''Queue11'''
* '''Queue10''' child
* '''Queue11''' child
* '''Queue12''' has two childs - '''Queue13''' and '''Queue14'''
* '''Queue13''' child
* '''Queue14''' child


<pre>
;;; Queue_A1 creation
/queue tree> add name=Queue_A1 parent='''ether1''' max-limit=2048k


=== Priorities, limits and amounts of incoming traffic ===
;;; Queue_B1 creation
/queue tree> add name=Queue_B1 parent=Queue_A1 max-limit=2048k limit-at=1024k


We will use 50Mbps as basic rate that is available to this particular HTB tree. Limitations and priorities are set according the rules mentioned earlier in this page.
;;; Queue_C1 creation
Amounts of incoming traffic are assigned to ensure meaningfulness of the example.
/queue tree> add name=Queue_C1 parent=Queue_A1 max-limit=2048k limit-at=1024k priority=7 \
packet-mark=server
;;; Queue_D1, Queue_E1 and Queue_F1 creation
/queue tree> add name=Queue_D1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
packet-mark=workstations
/queue tree> add name=Queue_E1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
packet-mark=workstations
/queue tree> add name=Queue_F1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
packet-mark=workstations
</pre>


All data can be seen in the table below:
Priority value by default is 8 so it is not specified here.   


[[Image:Stage1_1.jpg]]
Queue tree for download limitation is implemented on '''''ether2''''' interface.


=== Stage 1 - Satisfying the Limit-at===
<pre>
;;; Queue_A2 creation
/queue tree> add name=Queue_A2 parent='''ether1''' max-limit=2048k


;;; Queue_B2 creation
/queue tree> add name=Queue_B2 parent=Queue_A2 max-limit=2048k limit-at=1536k


;;; Queue_C creation
/queue tree> add name=Queue_C2 parent=Queue_A2 max-limit=2048k limit-at=512k priority=7 \
packet-mark=server


[[Image:Stage1_2.jpg]]
;;; Queue_D2, Queue_E2 and Queue_F2 creation
/queue tree> add name=Queue_D2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
packet-mark=workstations
/queue tree> add name=Queue_E2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
packet-mark=workstations
/queue tree> add name=Queue_F2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
packet-mark=workstations
</pre>




=== Stage 2 - Getting closer to Max-limit===
[[Image:Stage1_3.jpg]]


{{cont}}


[[image:Stage1_3.jpg|thumb|this is the description|250px]]


[[Category:Manual]]
[[Category:Manual|HTB]]
[[Category:Finished]]
[[Category:QoS|HTB]]
[[Category:Case Studies|HTB]]

Latest revision as of 07:02, 22 April 2019

Applies to RouterOS: 2.9, v3, v4

Theory

Structure

HTB (Hierarchical Token Bucket) is a classful queuing method that is useful for handling different kind of traffic. We have to follow three basic steps to create HTB:

  • Match and mark traffic – classify traffic for further use. Consists of one or more matching parameters to select packets for the specific class.
  • Create rules (policy) to mark traffic – put specific traffic class into specific queue and to define the actions that are taken for each class.
  • Attach policy for specific interface(-s) – append policy for all interfaces (global-in, global-out or global-total), for specific interface or for specific parent queue.

HTB allows to create a hierarchical queue structure and determine relations between queues, like "parent-child" or "child-child".

As soon as queue has at least one child it becomes a inner queue, all queues without children - leaf queues. Leaf queues make actual traffic consumption, Inner queues are responsible only for traffic distribution. All leaf queues are treated on equal basis.

In RouterOS it is necessary to specify parent option to assign queue as a child to other queue

Dual Limitation

Each queue in HTB has two rate limits:

  • CIR (Committed Information Rate) – (limit-at in RouterOS) worst case scenario, flow will get this amount of traffic no matter what (assuming we can actually send so much data)
  • MIR (Maximal Information Rate) – (max-limit in RouterOS) best case scenario, rate that flow can get up to, if there queue's parent has spare bandwidth

In other words, at first limit-at (CIR) of the all queues will be satisfied, only then child queues will try to borrow the necessary data rate from their parents in order to reach their max-limit (MIR).

Note: CIR will be assigned to the corresponding queue no matter what. (even if max-limit of the parent is exceeded)

That is why, to ensure optimal (as designed) usage of dual limitation feature, we suggest to stick to these rules:

  • Sum of committed rates of all children must be less or equal to amount of traffic that is available to parent.
CIR(parent)* ≥ CIR(child1) +...+ CIR(childN)
*in case if parent is main parent CIR(parent)=MIR(parent)
  • Maximal rate of any child must be less or equal to maximal rate of the parent
MIR (parent) ≥ MIR(child1) & MIR (parent) ≥ MIR(child2) & ... & MIR (parent) ≥ MIR(childN)


Queue colors in Winbox:

  • 0% - 50% available traffic used - green
  • 51% - 75% available traffic used - yellow
  • 76% - 100% available traffic used - red

Priority

We already know that limit-at (CIR) to all queues will be given out no matter what.

Priority is responsible for distribution of remaining parent queues traffic to child queues so that they are able to reach max-limit

Queue with higher priority will reach its max-limit before the queue with lower priority. 8 is the lowest priority, 1 is the highest.

Make a note that priority only works:

  • for leaf queues - priority in inner queue have no meaning.
  • if max-limit is specified (not 0)

Examples

In this section we will analyze HTB in action. To do that we will take one HTB structure and will try to cover all the possible situations and features, by changing the amount of incoming traffic that HTB have to recycle. and changing some options.


Structure

Our HTB structure will consist of 5 queues:

  • Queue01 inner queue with two children - Queue02 and Queue03
  • Queue02 inner queue with two children - Queue04 and Queue05
  • Queue03 leaf queue
  • Queue04 leaf queue
  • Queue05 leaf queue

Queue03, Queue04 and Queue05 are clients who require 10Mbps all the time Outgoing interface is able to handle 10Mbps of traffic.

Example 1 : Usual case

Structure

  • Queue01 limit-at=0Mbps max-limit=10Mbps
  • Queue02 limit-at=4Mbps max-limit=10Mbps
  • Queue03 limit-at=6Mbps max-limit=10Mbps priority=1
  • Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
  • Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 1

  • Queue03 will receive 6Mbps
  • Queue04 will receive 2Mbps
  • Queue05 will receive 2Mbps
  • Clarification: HTB was build in a way, that, by satisfying all limit-ats, main queue no longer have throughput to distribute

Example 2 : Usual case with max-limit

Structure

  • Queue01 limit-at=0Mbps max-limit=10Mbps
  • Queue02 limit-at=4Mbps max-limit=10Mbps
  • Queue03 limit-at=2Mbps max-limit=10Mbps priority=3
  • Queue04 limit-at=2Mbps max-limit=10Mbps priority=1
  • Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 2

  • Queue03 will receive 2Mbps
  • Queue04 will receive 6Mbps
  • Queue05 will receive 2Mbps
  • Clarification: After satisfying all limit-ats HTB will give throughput to queue with highest priority.

Example 3 : Inner queue limit-at

Structure

  • Queue01 limit-at=0Mbps max-limit=10Mbps
  • Queue02 limit-at=8Mbps max-limit=10Mbps
  • Queue03 limit-at=2Mbps max-limit=10Mbps priority=1
  • Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
  • Queue05 limit-at=2Mbps max-limit=10Mbps priority=5

Result of Example 3

  • Queue03 will receive 2Mbps
  • Queue04 will receive 6Mbps
  • Queue05 will receive 2Mbps
  • Clarification: After satisfying all limit-ats HTB will give throughput to queue with highest priority. But in this case inner queue Queue02 had limit-at specified, by doing so, it reserved 8Mbps of throughput for queues Queue04 and Queue05. From these two Queue04 have highest priority, that is why it gets additional throughput.

Example 4 : Leaf queue limit-at

Structure

  • Queue01 limit-at=0Mbps max-limit=10Mbps
  • Queue02 limit-at=4Mbps max-limit=10Mbps
  • Queue03 limit-at=6Mbps max-limit=10Mbps priority=1
  • Queue04 limit-at=2Mbps max-limit=10Mbps priority=3
  • Queue05 limit-at=12Mbps max-limit=15Mbps priority=5

Result of Example 4

  • Queue03 will receive ~3Mbps
  • Queue04 will receive ~1Mbps
  • Queue05 will receive ~6Mbps
  • Clarification: Only by satisfying all limit-ats HTB was forced to allocate 20Mbps - 6Mbps to Queue03, 2Mbps to Queue04, 12Mbps to Queue05, but our output interface is able to handle 10Mbps. As output interface queue is usually FIFO throughput allocation will keep ratio 6:2:12 or 3:1:6


HTB configuration example

Assume that we want to limit maximum download speed for subnet 10.1.1.0/24 to 2Mbps and distribute this amount of traffic between the server and workstations using HTB (limit upload to 2Mbps). Since HTB works in one direction and is implemented on outbound interface, HTB for download will be on ether2 and HTB for upload will be on ether1.

File:Image8008.gif


File:Image8009.gif



The first, we need to classify traffic.

Mark traffic form/to server. The first rule we will mark the outgoing connection from server and with the second one, all packets, which belong to this connection (download and upload packets for this connection): 


/ip firewall mangle> add chain=prerouting src-address=10.1.1.1/32 action=mark-connection \
new-connection-mark=server_con

/ip firewall mangle> add chain=forward connection-mark=server_con action=mark-packet  \
new-packet-mark=server


Do the same for workstation too. Match all workstation connections, mark it with the same mark (new-connection-mark=workstation_con) and after that mark all packets which belong to these workstation. 


/ip firewall mangle> add chain=prerouting src-address=10.1.1.2 
action=mark-connection new-connection-mark=workstation_con
/ip firewall mangle> add chain=prerouting src-address=10.1.1.3 
action=mark-connection new-connection-mark=workstation_con
/ip firewall mangle> add chain=prerouting src-address=10.1.1.4 
action=mark-connection new-connection-mark=workstation_con

/ip firewall mangle> add chain='''forward''' connection-mark=workstation_con  action=mark-packet \
new-packet-mark=workstations


At the end create /queue tree for upload and download based on figure 8.8 and figure 8.9.

Queue tree for upload limitation is implemented on ether1 interface. 

 ;;; Queue_A1 creation 
/queue tree> add name=Queue_A1 parent='''ether1''' max-limit=2048k 

 ;;; Queue_B1 creation 
/queue tree> add name=Queue_B1 parent=Queue_A1 max-limit=2048k limit-at=1024k

 ;;; Queue_C1 creation 
/queue tree> add name=Queue_C1 parent=Queue_A1 max-limit=2048k limit-at=1024k priority=7 \
packet-mark=server
 
 ;;; Queue_D1, Queue_E1 and Queue_F1 creation 
 /queue tree> add name=Queue_D1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
 packet-mark=workstations
 /queue tree> add name=Queue_E1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
 packet-mark=workstations
 /queue tree> add name=Queue_F1 parent=Queue_B1 max-limit=2048k limit-at=340k priority=8 \
 packet-mark=workstations

Priority value by default is 8 so it is not specified here.

Queue tree for download limitation is implemented on ether2 interface. 

 ;;; Queue_A2 creation
/queue tree> add name=Queue_A2 parent='''ether1''' max-limit=2048k 

 ;;; Queue_B2 creation 
/queue tree> add name=Queue_B2 parent=Queue_A2 max-limit=2048k limit-at=1536k

 ;;; Queue_C creation 
 /queue tree> add name=Queue_C2 parent=Queue_A2 max-limit=2048k limit-at=512k priority=7 \
 packet-mark=server

 ;;; Queue_D2, Queue_E2 and Queue_F2 creation
 /queue tree> add name=Queue_D2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
 packet-mark=workstations
 /queue tree> add name=Queue_E2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
 packet-mark=workstations
 /queue tree> add name=Queue_F2 parent=Queue_B2 max-limit=2048k limit-at=512k priority=8 \
 packet-mark=workstations


[ Top | Back to Content ]

Retrieved from "https://wiki.mikrotik.com/index.php?title=Manual:HTB&oldid=33128"