This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

quarta-feira, 31 de maio de 2017

Mikrotik - Bandwidth Control (apesar de antigo, esta melhor explicado que o o wiki do fornecedor)

General Information


Summary

Bandwidth Control is a set of mechanisms that control data rate allocation, delay variability, timely delivery, and delivery reliability. The MikroTik RouterOS supports the following queuing disciplines:
  • PFIFO - Packets First-In First-Out
  • BFIFO - Bytes First-In First-Out
  • SFQ - Stochastic Fairness Queuing
  • RED - Random Early Detect
  • PCQ - Per Connection Queue
  • HTB - Hierarchical Token Bucket

Specifications

Packages required: system
License required: Level1 (limited to 1 queue) , Level3
Submenu level: /queue
Standards and Technologies: None
Hardware usage: significant

Description

Quality of Service (QoS) means that the router should prioritize and shape network traffic. QoS is not so much about limiting, it is more about providing quality service to the network users. Some features of MikroTik RouterOS traffic control mechanism are listed below:
  • limit data rate for certain IP adresses, subnets, protocols, ports, and other parameters
  • limit peer-to-peer traffic
  • prioritize some packet flows over others
  • use queue bursts for faster web browsing
  • apply queues on fixed time intervals
  • share available traffic among users equally, or depending on the load of the channel
The queuing is applied on packets leaving the router through a real interface (i.e., the queues are applied on the outgoing interface, regarding the traffic flow), or any of the 3 additional virtual interfaces (global-in, global-out, global-total).
The QoS is performed by means of dropping packets. In case of TCP protocol, the dropped packets will be resent on a slower rate, so there is no need to worry that with shaping we lose some TCP information.
The main terms used to describe the level of QoS for network applications, are:
  • queuing discipline (qdisc) - an algorithm that holds and maintains a queue of packets. It accumulates the packets and decides the order of the outgoing packets (it means that queuing discipline can reorder packets). Qdisc also decides which packets to drop if there is no space for them.
  • CIR (Committed Information Rate) - the guaranteed data rate. It means that traffic rate, not exceeding this value should always be delivered
  • MIR (Maximal Information Rate) - the maximal data rate router will provide
  • Priority - the order of importance in what traffic will be processed. You can give priority to some traffic in order it to be handeled before some other traffic
  • Contention Ratio - the ratio to which the defined data rate is shared among users (when a certain data rate is allocated to a number of subscribers). It is the number of subscribers that have a single speed limitation, applied to all of them together. For example, the contention ratio of 1:4 means that the allocated data rate may be shared between no more than 4 users
Before sending data over an interface, it is processed with a queuing discipline. There can be only one queueing discipline per interface, which, by default, is set under /queue interface for each physical interface (there is no default queuing discipline for virtual interfaces). Once we add a first queue (in /queue tree or /queue simple) to a physical interface, the interface default queue is replaced by HTB hierarchy with that queue, but the one defined in /queue interface for that particular interface, is no more active.
Scheduler and Shaper qdiscs
We can classify queuing disciplines by their influence to packet flow:
  • schedulers - queuing disciplines only reschedule packets regarding their algorithm and drop packets which 'do not fit in the queue'. Scheduler queuing disciplines are: PFIFO, BFIFO, SFQ, PCQ (both scheduler and shaper), RED
  • shapers - queuing disciplines that also perform the limitation. Shapers are PCQ (both scheduler and shaper) and HTB
Virtual Interfaces
There are 3 virtual interfaces in RouterOS, in addition to real interfaces:
  • global-in - represents all the input interfaces in general (INGRESS queue). Please note that queues attached to global-in apply to traffic that is received by the router, before the packet filtering. global-in queueing is executed just after mangle and dst-nat
  • global-out - represents all the output interfaces in general (EGRESS queue). Queues attached to it apply before the ones attached to a specific interface
  • global-total - represents a virtual interface through which all the data, going through the router, is passing. When attaching a qdisc to global-total, the limitation is done in both directions. For example, if we set a total-max-limit to 256000, we will get upload+download=256kbps (maximum)
Introduction to HTB
HTB (Hierarchical Token Bucket) is a classful queuing discipline that is useful for applying different handling for different kinds of traffic. The queues you add in /queue simple and /queue tree are attached to the main Hierarchical Token Bucket (HTB). For example, you can set a maximum data rate for a workgroup and then distribute that amount of traffic between the members of that workgroup.
HTB qdisc in detail:

HTB terms:
  • filter - a procedure that classifies packets. The filters are responsible for classifying packets so that they are put in the corresponding qdiscs. All filters are applied at the HTB root and classify packets directly into the qdiscs, without traversing the HTB tree. If a packet is not classified into any of the qdiscs, it is sent out to the interface directly, traversing the HTB, so no HTB rules are applied to those packets (it would mean effective higher priority than of any packet flow managed by HTB).
  • level - position of a class in the hierarchy.
  • class - algorithm for limiting traffic flow to a certain rate. It does not store any packets (this function can only be performed by a queue). A class may contain either one or more subclasses (inner class), or one and only one qdisc (leaf class).
  • inner class - a class that has one or more child class attached to it. As inner classes do not store any packets, qdiscs can not be attached to them (so their qdisc and filter settings are ignored, although may be still shown in RouterOS configuration), so they only do traffic shaping. Priority setting is ignored as well.
  • leaf class - a class that has a parent but does not have any child classes. Leaf classes are always located at level 0 of the hierarchy. Each leaf class has one and only one qdisc attached to it, with a certain priority.
  • self feed - an exit (out of the HTB tree, to the interface) for the packets from all the classes active on its level of the hierarchy. There is one self feed per level, each consisting of 8 self slots that represent priorities.
  • self slot - an element of a self feed that corresponds to each particular priority. There is one self slot per priority per level. All classes, active at the same level, having the same priority are attached to one self slot that they are using to send packets out through.
  • active class (at a particular level) - a class that is attached to a self slot at the given level.
  • inner feed - similar to a self feed object, which consists of inner self slots, present on each inner class. There is one inner feed per inner class.
  • inner feed slot - similar to self slot. Each inner feed consists of inner slots which represent a priority.
Each class has a parent and may have one or more children. Classes that do not have children, are put at level 0, where queues are maintained, and are called 'leaf classes'.
Each class in the hierarchy can prioritize and shape traffic. There are two main parameters, which refer to shaping and one - to prioritizing:
  • limit-at - normal data rate that is guaranteed to a class (CIR)
  • max-limit - maximal data rate that is allowed for a class to reach (MIR)
  • priority - order in which classes are served at the same level (8 is the lowest priority, 1 is the highest)
Each HTB class can be in one of 3 states, depending on data rate that it consumes:
  • green - a class the actual rate of which is equal or less than limit-at. At this state, the class is attached to self slot at the corresponding priority at its level, and is allowed to satisfy its CIR limitation regardless of what limitations its parents have. For example, if we have a leaf class with limit-at=512000 and its parent has max-limit=limit-at=128000, the class will still get its 512kbps! All CIRs of a particular level are satisfied before all MIRs of the same level and any limitations of higher levels.
  • yellow - a class the actual rate of which is greater than limit-at and equal or less than max-limit (or burst-limit if burst is active). At this state, the class is attached to the inner slot of the corresponding priority of its parent's inner feed, which, in turn, may be attached to either its parent's inner slot of the same priority (in case the parent is also yellow), or to its own level self slot of the same priority (in case the parent is green). Upon the transition to this state, the class 'disconnects' from self feed of its level, and 'connects' to its parent's inner feed.
  • red - a class the actual rate of which exceeds max-limit (or burst-limit if burst is active). This class cannot borrow rate from its parent class.
Note: as CIRs are always satisfied before MIRs or other limitations of higher levels are consulted, you should always ensure that the limit-at property of any inner class is equal or greater than the sum of all limit-at parameter of the children of that inner class.
Priorities
When there is a possibility to send out a packet, HTB queries all its self slots in order of priority, starting with highest priority on the lowest level, till lowest priority on highest level. Each leaf class (packets are stored and enqueued only within qdiscs attached to each leaf class) is ultimately connected to a certain self slot, either directly or through a chain of parent classes:

As you can see from the picture, leaf-classes that are in the green state will always have a higher effective priority than those that are yellow (and, thus, borrowing their rate from parent classes), because their priority is at a lower level (level 0). In this picture, Leaf1 will be served only after Leaf2, although it has a higher priority (priority 7) than Leaf1 (priority 8).
In case of equal priorities and equal states, HTB serves these classes, using round robin algorithm.
HTB Examples
Here are some examples on how the HTB works.
Imagine the following scenario - we have 3 different kinds of traffic, marked in /ip firewall mangle (packet_mark1, packet_mark2 and packet_mark3), and now have bulit a HTB hierarchy:
[admin@MikroTik] queue tree> add name=ClassA parent=Local max-limit=2048000
[admin@MikroTik] queue tree> add name=ClassB parent=ClassA max-limit=1024000
[admin@MikroTik] queue tree> add name=Leaf1 parent=ClassA max-limit=2048000 \
\... limit-at=1024000 packet-mark=packet_mark1 priority=8
[admin@MikroTik] queue tree> add name=Leaf2 parent=ClassB max-limit=1024000 \
\... limit-at=256000 packet-mark=packet_mark2 priority=7
[admin@MikroTik] queue tree> add name=Leaf3 parent=ClassB max-limit=1024000 \
\... limit-at=768000 packet-mark=packet_mark3 priority=8
[admin@MikroTik] queue tree> print
Flags: X - disabled, I - invalid
 0   name="ClassA" parent=Local packet-mark="" limit-at=0 queue=default
     priority=8 max-limit=2048000 burst-limit=0 burst-threshold=0
     burst-time=0s

 1   name="ClassB" parent=ClassA packet-mark="" limit-at=0 queue=default
     priority=8 max-limit=1024000 burst-limit=0 burst-threshold=0
     burst-time=0s

 2   name="Leaf1" parent=ClassA packet-mark=packet_mark1 limit-at=1024000
     queue=default priority=8 max-limit=2048000 burst-limit=0
     burst-threshold=0 burst-time=0s

 3   name="Leaf2" parent=ClassB packet-mark=packet_mark2 limit-at=256000
     queue=default priority=7 max-limit=1024000 burst-limit=0
     burst-threshold=0 burst-time=0s

 4   name="Leaf3" parent=ClassB packet-mark=packet_mark3 limit-at=768000
     queue=default priority=8 max-limit=1024000 burst-limit=0
     burst-threshold=0 burst-time=0s
[admin@MikroTik] queue tree>
Now let us describe some scenarios, using this HTB hierarchy.
  1. Imagine a situation when packets have arrived at Leaf1 and Leaf2. Because of this, Leaf1 attaches itself to this level's (Level 0) self slot with priority=8 and Leaf2 attaches to self slot with priority=7. Leaf3 has nothing to send, so it does nothing.

    This is a simple situation: there are two active classes (Leaf1 and Leaf2) at Level 0, and as they both are in green state, they are processed in order of their priorities - at first, we serve Leaf2, then Leaf1.
  2. Now assume that Leaf2 has to send more than 256kbps, so it needs to go over it's green limit. With the state change, it attaches itself to its parent's (ClassB) inner feed, which recursively attaches itself to Level1 self slot at priority 7. Leaf1 remains in green state - it has packets to send, but their rate is lower than 1Mbps. Leaf3 still has nothing to send.

    It is very important to understand that Leaf1 now has higher effective priority than Leaf2 (when it is in green state), although we have configured it for a lower priority (8) than Leaf2. It is because Leaf2 has disconnected itself from self feed at Level 0 and is now borrowing rate from its parent (ClassB), which, in turn, has attached to a self feed at Level 1. Thus, the priority of Leaf2 has jumped to Level1. Remember that lowest level is served first, than the next level, and so on, satisfying the attached classes in order of their priority.
  3. Consider that Leaf1 has reached its max-limit and changed its state to red, and Leaf2 now uses more than 1Mbps (and less than 2Mbps), so its parent ClassB has to borrow from ClassA and becomes yellow. Leaf3 still has no packets to send.

    This scenario shows that Leaf1 has reached its max-limit and cannot even borrow from its parent (ClassA), so it is detached from all self slots and inner slots. Leaf2 has recursively reached Level 2, as it borrows from ClassB which, in turn, borrows from ClassA, as it does not have enough rate available. As Leaf3 has no packets to send, the only class that sends is Leaf2.
  4. Assume that ClassA reaches its max-limit (2Mbps), so neither ClassB, nor Leaf2 can send as they only rely on borrowing rate, which is impossible as ClassA cannot send. But now, Leaf3 has some packets to send:

    In this situation Leaf2 is in yellow state, but it cannot borrow (as Class B cannot borrow from Class A) and Leaf3 is the only class that can send. Note that even though no other calsses, including its parents is able to send, Leaf3 can send perfectly well while is is attached to the Level 0 self feed.
  5. Finally, let's see what happens, if Leaf1, Leaf2, Leaf3 and ClassB are in the yellow state, and ClassA is green.

    Leaf1 borrows from ClassA, Leaf2 and Leaf3 - from ClassB, and ClassB, in turn, borrows from ClassA. Now all the priorities have 'moved' to Level 2. So Leaf2 is on the highest priority and is served first. As Leaf1 and Leaf3 are of the same priority (8) on the same level (2), they are served using round robin algorithm.
Bursts
Bursts are used to allow higher data rates for a short period of time. Every 1/16 part of the burst-time, the router calculates the average data rate of each class over the last burst-time seconds. If this average data rate is less than burst-threshold, burst is enabled and the effective rate limit (transition to the red state) is set to burst-limit bps, otherwise the effective maximal limit falls to max-limit.
Let us consider the following setup: max-limit=256000, burst-time=8, burst-threshold=192000 and burst-limit=512000. When a user is starting to download a file via HTTP, we can observe such situation:

At the beginning the average data rate over the past 8 seconds is 0bps because no traffic has passed through this ruke before it has been created. Since this average data rate is less than burst-threshold (192kbps), burst is allowed. After the first second, the average data rate is (0+0+0+0+0+0+0+512)/8=64kbps, which is less than burst-threshold. After the second second, average data rate is (0+0+0+0+0+0+512+512)/8=128kbps. After the third second comes the breakpoint when the average data rate becomes larger than burst-threshold. At this moment burst is disabled and the effective data rate limitation falls down to max-limit (256kbps).
Note how the burst-time was used. The actual duration of burst does not depend of burst-time alone! It also depends on the burst-threshold/burst-limit ratio and the actual data rate passing through the bursty class. In this example the burst ratio was 192000/512000=3/8, the time was 8, and the queue has been trying to utilize all available rate the class was providing, so the burst was 3 seconds long.
Now you can easily see why the burst-threshold should be between limit-at and max-limit for normal operation. If you specify burst-threshold higher than max-limit, then the average rate will tend to burst-threshold, but the effective maximal limit will jump between max-limit and burst-limit constantly (depending on the actual traffic rate, it may happen even on each evaluation point (1/16th of burst-time)).
HTB in RouterOS
In addition to interface queues (one queue or HTB tree per interface), 3 virtual 4 HTB trees maintained by RouterOS:
  • global-in
  • global-total
  • global-out
When adding a simple queue, it creates 3 HTB classes (in global-in, global-total and global-out), but it does not add any classes in interface queue. Queue tree is more flexible - you can add it to any of these HTB's.
When packet travels through the router, it passes 4 HTB trees - global-in, global-total, global-out and output interface queue. If it is directed to the router, it passes global-in and global-total HTB queues. If packets are sent from the router, they go through global-total, global-out and output interface queues

Additional Resources


Queue Types

Submenu level: /queue type

Description

You can create your custom queue types in this submenu. Afterwards, you will be able to use them in /queue tree, /queue simple or /queue interface. Note that these queueing disciplines can not limit data rate at all (except for PCQ) - they only reorganize (schedule) packets and drop excess ones (if the queue is getting too long and the managing class can not send the packets quickly enough), so you won't find any rate limitation parameters here (except for PCQ) - only storage limits. Note also that the scheduling is only taking place when the packets are being enqueued in the qdisc, and this only happens when the packets are coming in at the rate faster than the managing class can provide (so this is only a buffer). There are 5 kinds of qdiscs that can be used for storing packets:
PFIFO and BFIFO
These queuing disciplines are based on the FIFO algorithm (First-In First-Out). The difference between PFIFO and BFIFO is that one is measured in packets and the other one in bytes. There is only one parameter called pfifo-limit (or bfifo-limit in case of BFIFO) which defines how much data a FIFO queue can hold. Every packet that cannot be enqueued (if the queue is full), is dropped. Large queue sizes can increase latency, but utilize channel better.

Use FIFO queuing disciplines if you have a noncongested link.
SFQ
Stochastic Fairness Queuing (SFQ) equalizes traffic flows (TCP sessions or UDP streams) when the link is completely full.
The fairness of SFQ is ensured by hashing and round-robin algorithms. Hashing algorithm divides the session traffic over a limited number of subqueues. A traffic flow may be uniquely identified by a tuple (src-address, dst-address, src-port and dst-port), so these parameters are used by SFQ hashing algorithm to classify packets into subqueues.

The whole SFQ queue can contain 128 packets and there are 1024 subqueues available for these packets. Each packet stored in a FIFO-like 128 packet buffer, belongs to a certain subqueue, determined by the hash function (a simple function of the tuple values with 10-bit output is used, hence the amount of subqueues is 1024). Stochastic nature of the queueing discipline is observed in that packets from an unpredictable number of flows may actually be classified in the same subqueue. After sfq-perturb seconds the hashing algorithm changes and divides the session traffic to other subqueues, so that no separate data flows will be associated with the same subqueue for a long time. The round-robin algorithm dequeues pcq-allot bytes from each subqueue in a turn.
Use SFQ for congested links to ensure that connections do not starve. SFQ is especially benefitial on wireless links.
PCQ
To solve some SFQ imperfectness, Per Connection Queuing (PCQ) was created. It is the only classless queuing type in RouterOS that can do rate limitation. It is an improved version of SFQ without its stohastic nature. PCQ also creates subqueues, based on the pcq-classifier parameter. Each subqueue has a data rate limit of pcq-rate and size of pcq-limit packets. The total size of a PCQ queue cannot be greater than pcq-total-limit packets.
The following example demonstrates the usage of PCQ with packets, classified by their source address.

If you classify the packets by src-address then all packets with different source IP addresses will be grouped into different subqueues. Now you can do the limitation or equalization for each subqueue with the pcq-rate parameter. Perhaps, the most significant part is to decide to which interface should we attach this queue. If we will attach it to the Local interface, all traffic from the Public interface will be grouped by src-address (probably it's not what we want), but if we attach it to the Public interface, all traffic from our clients will be grouped by src-address - so we can easily limit or equalize upload for clients. Same can be done for downloads, but in that case dst-address classifier will be used, and PCQ put on the locan interface.
To equalize rate among subqueues, classified by the pcq-classifier, set the pcq-rate to 0! PCQ can be used to dynamically equalize or shape traffic for multiple users, using little administration. In fact, PCQ always equalizes the subqueues, so the pcq-rate is just a cap for equalization - a subqueue may get smaller rate, but will never get higher rate.
RED
Random Early Detection (also known as Random Early Drop, as this is how it actually works) is a queuing mechanism which tries to avoid network congestion by controlling the average queue size. When the average queue size reaches red-min-threshold, RED starts to drop packets randomly with linearly increasing probability as the average queue size grows up until the average queue size reaches the red-max-threshold. The effective queue size at any moment could be higher than the red-max-threshold as the probability does not grow very fast, so it is possible to specify a hard limit for the queue size. When the average queue size reaches red-max-threshold or becomes larger, all further packats are dropped until the average queue size does not drop below this valus (at which point probalistic calculations will be activated again).
The average queue size avg is (1-W)*avg+W*q, where
  • q - current queue length
  • W - queue weight defined as burst+1-min=(1-(1-W)^burst)/W. Note that log(W) value ir rounded to integer (so W can be 1, 0.1, 0.01, etc.). It is determined experimantally that in many generic cases, W is near to min/10*burst
The pb probability value is increasing linearly from 0% to 2% as the average queue size grows from red-min-threshold to red-max-threshold: pb=0.02*(avg-min)/(max-min).
The packet dropping probability pb is increasing with pb and with enqueued packet count since the last packet was dropped: pa=pb/(1-count*pb).
It is defined experimentally that a good red-burst value is (min+2*max)/3. And a good red-max-threshold is twice red-min-threshold.
Note that in the formulas above, min means red-min-threshold, max means red-max-threshold and burst means red-burst.

Used on congested links with high data rates, as it is fast and TCP-friendly.

Property Description

bfifo-limit (integer; default: 15000) - maximum number of bytes that the BFIFO queue can holdkind (bfifo | pcq | pfifo | red | sfq) - which queuing discipline to use
bfifo - Bytes First-In, First-Out
pcq - Per Connection Queue
pfifo - Packets First-In, First-Out
red - Random Early Detection
sfq - Stohastic Fairness Queuing
name (name) - reference name of the queue typepcq-classifier (dst-address | dst-port | src-address | src-port; default: "") - list classifiers for grouping packets into PCQ subqueues. Several classifiers can be used at once, e.g., src-address,src-port will group all packets with different source address and source-ports into separate subqueuespcq-limit (integer; default: 50) - number of packets that a single PCQ sub-queue can holdpcq-rate (integer; default: 0) - maximal data rate allowed for each PCQ sub-queue. This is a rate cap, as the subqueues will be equalized anyway
0 - no limitation set (only equalize rates between subqueues)
pcq-total-limit (integer; default: 2000) - number of packets that the whole PCQ queue can holdpfifo-limit (integer) - maximum number of packets that the PFIFO queue can holdred-avg-packet (integer; default: 1000) - average packet size, used for tuning average queue recalculation timered-burst (integer) - a measure of how fast the average queue size will be influenced by the real queue size, given in bytes. Larger values will smooth the changes, so longer bursts will be allowedred-limit (integer) - hard limit on queue size in bytes. If the real queue size (not average) exceeds this value then all further packets will be discarded until the queue size drops below. This should be higher than red-max-threshold+red-burstred-max-threshold (integer) - upper limit for average queue size, in bytes. When the size reaches this value, all further packets shall be droppedred-min-threshold (integer) - lower limit for average queue size, in bytes. When the size reaches this value, RED starts to drop packets randomly with a calculated probabilitysfq-allot (integer; default: 1514) - amount of bytes that a subqueue is allowed to send before the next subqueue gets a turn (amount of bytes which can be sent from a subqueue in a single round-robin turn), should be at least 1514 for links with 1500 byte MTUsfq-perturb (integer; default: 5) - how often to shake (perturb) SFQ's hashing algorithm, in seconds

Interface Default Queues

Submenu level: /queue interface

Description

In order to send packets over an interface, they have to be enqueued in a queue even if you do not want to limit traffic at all. Here you can specify the queue type which will be used for transmitting data.
Note that once you configure tree queues for a listed interface, the interface default queue is no longer active for that particular interface, so you need to make sure all packets that goes out through this interface are filtered into some qdiscs inside the HTB tree. Otherwise the packets that are not filtered, are sent out directly (at effective higher priority than any of the packets in the HTB tree), and unbuffered, which ultimately lead to suboptimal performance.

Property Description

interface (read-only: name) - name of the interfacequeue (name; default: default) - queue type which will be used for the interface

Example

Set the wireless interface to use wireless-default queue:
[admin@MikroTik] queue interface> set 0 queue=wireless-default
[admin@MikroTik] queue interface> print
 # INTERFACE QUEUE
 0 wlan1     wireless-default
[admin@MikroTik] queue interface>

Simple Queues


Description

The simpliest way to limit data rate for specific IP addresses and/or subnets, is to use simple queues.
You can also use simple queues to build advanced QoS applications. They have useful integrated features:
  • Peer-to-peer traffic queuing
  • Applying queue rules on chosen time intervals
  • Priorities
  • Using multiple packet marks from /ip firewall mangle
  • Shaping of bidirectional traffic (one limit for the total of upload + download)

Property Description

burst-limit (integer/integer) - maximum data rate which can be reached while the burst is active, in form of in/out (target upload/download)burst-threshold (integer/integer) - average data rate limit, until which the burst is allowed. If the average data rate over the last burst-time seconds is less than burst-threshold, the actual data rate may reach burst-limit. Otherwise the hard limit is reset to max-limit. Set in form of in/out (target upload/download)burst-time (integer/integer) - period of time, in seconds, over which the average data rate is calculated, in form of in/out (target upload/download)direction (none both upload download) - traffic flow directions from the targets' point of view, affected by this queue
none - the queue is effectively inactive
both - the queue limits both target upload and target download
upload - the queue limits only target upload, leaving the download rates unlimited
download - the queue limits only target download, leaving the upload rates unlimited
dst-address (IP address/netmask) - destination address to matchdst-netmask (netmask) - netmask for dst-address interface (text) - interface, this queue applies to (i.e., the interface the target is connected to)limit-at (integer/integer) - CIR, in form of in/out (target upload/download)max-limit (integer/integer) - MIR (in case burst is not active), in form of in/out (target upload/download)name (text) - descriptive name of the queuep2p (all-p2p | bit-torrent | blubster | direct-connect | edonkey | fasttrack | gnutella | soulseek | winmx) - which type of P2P traffic to match
all-p2p - match all P2P traffic
packet-marks (multiple choice: name; default: "") - list of packet marks (set by /ip firewall mangle) to match. Multiple packet marks are separated by commas (",")parent (name) - name of the parent queue in the hierarchy. Can only be another simple queuepriority (integer: 1..8) - priority of the queue. 1 is the highest, 8 - the lowestqueue (name/name; default: default/default) - name of the queue from /queue type, in form of in/outtarget-addresses (multiple choice: IP address/netmask) - limitation target IP addresses (source addresses). Multiple addresses are separated by commastime (time-time,sat | fri | thu | wed | tue | mon | sun{+}; default: "") - limit queue effect to a specified time periodtotal-burst-limit (integer) - burst limit for global-total (cumulative rate, upload + download) queuetotal-burst-threshold (integer) - burst threshold for global-total (cumulative rate, upload + download) queuetotal-burst-time (time) - burst time for global-total queuetotal-limit-at (integer) - limit-at for global-total (cumulative rate, upload + download) queuetotal-max-limit (integer) - max-limit for global-total (cumulative rate, upload + download) queuetotal-queue (name) - queuing discipline to use for global-total queue

Queue Trees

Submenu level: /queue tree

Description

The queue trees should be used when you want to use sophisticated data rate allocation based on protocols, ports, groups of IP addresses, etc. At first you have to mark packet flows with a mark under /ip firewall mangle and then use this mark as an identifier for packet flows in queue trees.

Property Description

burst-limit (integer) - maximum data rate which can be reached while the burst is activeburst-threshold (integer) - average data rate limit, until which the burst is allowed. If the average data rate over the last burst-time seconds is less than burst-threshold, the actual data rate may reach burst-limit. Otherwise the hard limit is reset to max-limitburst-time (time) - period of time, in seconds, over which the average data rate is calculatedlimit-at (integer) - CIRmax-limit (integer) - MIR (in case burst is not active)name (text) - descriptive name for the queuepacket-mark (text) - packet flow mark (set by /ip firewall mangle) to match. This creates a filter that puts the packets with the given mark into this queueparent (text) - name of the parent queue. The top-level parents are the available interfaces (actually, main HTB). Lower level parents can be other tree queuespriority (integer: 1..8) - priority of the queue. 1 is the highest, 8 - the lowestqueue (text) - name of the queue type. Types are defined under /queue type

Application Examples


Example of emulating a 128Kibps/64Kibps Line

Assume, we want to emulate a 128Kibps download and 64Kibps upload line, connecting IP network 192.168.0.0/24. The network is served through the Local interface of customer's router. The basic network setup is in the following diagram:

To solve this situation, we will use simple queues.
IP addresses on MikroTik router:
[admin@MikroTik] ip address> print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   192.168.0.254/24   192.168.0.0     192.168.0.255   Local
 1   10.5.8.104/24      10.5.8.0        10.5.8.255      Public
[admin@MikroTik] ip address>
And routes:
[admin@MikroTik] ip route> print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        G GATEWAY         DIS INTE...
 0 A S  0.0.0.0/0                          r 10.5.8.1        1   Public
 1 ADC  10.5.8.0/24        10.5.8.104                        0   Public
 2 ADC  192.168.0.0/24     192.168.0.254                     0   Local
[admin@MikroTik] ip route>
Add a simple queue rule, which will limit the download traffic to 128Kib/s and upload to 64Kib/s for clients on the network 192.168.0.0/24, served by the interface Local:
[admin@MikroTik] queue simple> add name=Limit-Local interface=Local \
\... target-address=192.168.0.0/24 max-limit=65536/131072
[admin@MikroTik] queue simple> print
Flags: X - disabled, I - invalid, D - dynamic
 0    name="Limit-Local" target-addresses=192.168.0.0/24 dst-address=0.0.0.0/0
      interface=Local parent=none priority=8 queue=default/default
      limit-at=0/0 max-limit=65536/131072 total-queue=default
[admin@MikroTik] queue simple>
The max-limit parameter cuts down the maximum available bandwidth. From the clients' point of view, the value 65536/131072 means that they will get maximum of 131072bps for download and 65536bps for upload. The target-addresses parameter defines the target network (or networks, separated by a comma) to which the queue rule will be applied.
Now see the traffic load:
[admin@MikroTik] interface> monitor-traffic Local
  received-packets-per-second: 7
       received-bits-per-second: 68kbps
        sent-packets-per-second: 13
           sent-bits-per-second: 135kbps

[admin@MikroTik] interface>
Probably, you want to exclude the server from being limited, if so, add a queue for it without any limitation (max-limit=0/0 which means no limitation) and move it to the beginning of the list:
[admin@MikroTik] queue simple> add name=Server target-addresses=192.168.0.1/32 \
\... interface=Local
[admin@MikroTik] queue simple> print
Flags: X - disabled, I - invalid, D - dynamic
 0    name="Limit-Local" target-addresses=192.168.0.0/24 dst-address=0.0.0.0/0
      interface=Local parent=none priority=8 queue=default/default
      limit-at=0/0 max-limit=65536/131072 total-queue=default

 1    name="Server" target-addresses=192.168.0.1/32 dst-address=0.0.0.0/0
      interface=Local parent=none priority=8 queue=default/default
      limit-at=0/0 max-limit=0/0 total-queue=default
[admin@MikroTik] queue simple> mo 1 0
[admin@MikroTik] queue simple> print
Flags: X - disabled, I - invalid, D - dynamic
 0    name="Server" target-addresses=192.168.0.1/32 dst-address=0.0.0.0/0
      interface=Local parent=none priority=8 queue=default/default
      limit-at=0/0 max-limit=0/0 total-queue=default

 1    name="Limit-Local" target-addresses=192.168.0.0/24 dst-address=0.0.0.0/0
      interface=Local parent=none priority=8 queue=default/default
      limit-at=0/0 max-limit=65536/131072 total-queue=default
[admin@MikroTik] queue simple>

Queue Tree Example With Masquerading

In the previous example we dedicated 128Kib/s download and 64Kib/s upload traffic for the local network. In this example we will guarantee 256Kib/s download (128Kib/s for the server, 64Kib/s for the Workstation and also 64Kib/s for the Laptop) and 128Kib/s for upload (64/32/32Kib/s, respectivelly) for local network devices. Additionally, if there is spare bandwidth, share it among users equally. For example, if we turn off the laptop, share its 64Kib/s download and 32Kib/s upload to the Server and Workstation.
When using masquerading, you have to mark the outgoing connection with new-connection-mark and take the mark-connection action. When it is done, you can mark all packets which belong to this connection with the new-packet-mark and use the mark-packet action.

  1. At first, mark the Server's download and upload traffic. With the first rule we will mark the outgoing connection and with the second one, all packets, which belong to this connection:
    [admin@MikroTik] ip firewall mangle> add src-address=192.168.0.1/32 \
    \... action=mark-connection new-connection-mark=server-con chain=prerouting
    [admin@MikroTik] ip firewall mangle> add connection-mark=server-con \
    \... action=mark-packet new-packet-mark=server chain=prerouting
    [admin@MikroTik] ip firewall mangle> print
    Flags: X - disabled, I - invalid, D - dynamic
     0   chain=prerouting src-address=192.168.0.1 action=mark-connection
         new-connection-mark=server-con
    
     1   chain=prerouting connection-mark=server-con action=mark-packet
         new-packet-mark=server
    [admin@MikroTik] ip firewall mangle>
  2. The same for Laptop and Workstation:
    [admin@MikroTik] ip firewall mangle> add src-address=192.168.0.2 \
    \... action=mark-connection new-connection-mark=lap_works-con chain=prerouting
    [admin@MikroTik] ip firewall mangle> add src-address=192.168.0.3 \
    \... action=mark-connection new-connection-mark=lap_works-con chain=prerouting
    [admin@MikroTik] ip firewall mangle> add connection-mark=lap_works-con \
    \... action=mark-packet new-packet-mark=lap_work chain=prerouting
    [admin@MikroTik] ip firewall mangle> print
    Flags: X - disabled, I - invalid, D - dynamic
     0   chain=prerouting src-address=192.168.0.1 action=mark-connection
         new-connection-mark=server-con
    
     1   chain=prerouting connection-mark=server-con action=mark-packet
         new-packet-mark=server
    
     2   chain=prerouting src-address=192.168.0.2 action=mark-connection
         new-connection-mark=lap_works-con
    
     3   chain=prerouting src-address=192.168.0.3 action=mark-connection
         new-connection-mark=lap_works-con
    
     4   chain=prerouting connection-mark=lap_works-con action=mark-packet
         new-packet-mark=lap_work
    [admin@MikroTik] ip firewall mangle>
    As you can see, we marked connections that belong for Laptop and Workstation with the same flow.
  3. In /queue tree add rules that will limit Server's download and upload:
    [admin@MikroTik] queue tree> add name=Server-Download parent=Local \
    \... limit-at=131072 packet-mark=server max-limit=262144
    [admin@MikroTik] queue tree> add name=Server-Upload parent=Public \
    \... limit-at=65536 packet-mark=server max-limit=131072
    [admin@MikroTik] queue tree> print
    Flags: X - disabled, I - invalid
     0   name="Server-Download" parent=Local packet-mark=server limit-at=131072
         queue=default priority=8 max-limit=262144 burst-limit=0
         burst-threshold=0 burst-time=0s
    
     1   name="Server-Upload" parent=Public packet-mark=server limit-at=65536
         queue=default priority=8 max-limit=131072 burst-limit=0
         burst-threshold=0 burst-time=0s
    [admin@MikroTik] queue tree>
    And similar config for Laptop and Workstation:
    [admin@MikroTik] queue tree> add name=Laptop-Wkst-Down parent=Local \
    \... packet-mark=lap_work limit-at=65535 max-limit=262144
    [admin@MikroTik] queue tree> add name=Laptop-Wkst-Up parent=Public \
    \... packet-mark=lap_work limit-at=32768 max-limit=131072
    [admin@MikroTik] queue tree> print
    Flags: X - disabled, I - invalid
     0   name="Server-Download" parent=Local packet-mark=server limit-at=131072
         queue=default priority=8 max-limit=262144 burst-limit=0
         burst-threshold=0 burst-time=0s
    
     1   name="Server-Upload" parent=Public packet-mark=server limit-at=65536
         queue=default priority=8 max-limit=131072 burst-limit=0
         burst-threshold=0 burst-time=0s
    
     2   name="Laptop-Wkst-Down" parent=Local packet-mark=lap_work limit-at=65535
         queue=default priority=8 max-limit=262144 burst-limit=0
         burst-threshold=0 burst-time=0s
    
     3   name="Laptop-Wkst-Up" parent=Public packet-mark=lap_work limit-at=32768
         queue=default priority=8 max-limit=131072 burst-limit=0
         burst-threshold=0 burst-time=0s
    [admin@MikroTik] queue tree>

Equal bandwidth sharing among users

This example shows how to equally share 10Mibps download and 2Mbps upload among active users in the network 192.168.0.0/24. If Host A is downloading 2 Mbps, Host B gets 8 Mbps and vice versa. There might be situations when both hosts want to use maximum bandwidth (10 Mbps), then they will receive 5 Mbps each, the same goes for upload. This setup is also valid for more than 2 users.

At first, mark all traffic, coming from local network 192.168.0.0/24 with a mark users:
/ip firewall mangle add chain=forward src-address=192.168.0.0/24 \
   action=mark-connection new-connection-mark=users-con
/ip firewall mangle add connection-mark=users-con action=mark-packet \
   new-packet-mark=users chain=forward
Now we will add 2 new PCQ types. The first, called pcq-download will group all traffic by destination address. As we will attach this queue type to the Local interface, it will create a dynamic queue for each destination address (user) which is downloading to the network 192.168.0.0/24. The second type, called pcq-upload will group the traffic by source address. We will attach this queue to the Public interface so it will make one dynamic queue for each user who is uploading to Internet from the local network 192.168.0.0/24.
/queue type add name=pcq-download kind=pcq pcq-classifier=dst-address
/queue type add name=pcq-upload kind=pcq pcq-classifier=src-address
Finally, make a queue tree for download traffic:
/queue tree add name=Download parent=Local max-limit=10240000
/queue tree add parent=Download queue=pcq-download packet-mark=users
And for upload traffic:
/queue tree add name=Upload parent=Public max-limit=2048000
/queue tree add parent=Upload queue=pcq-upload packet-mark=users
Note! If your ISP cannot guarantee you a fixed amount of traffic, you can use just one queue for upload and one for download, attached directly to the interface:
/queue tree add parent=Local queue=pcq-download packet-mark=users
/queue tree add parent=Public queue=pcq-upload packet-mark=users
 
 
 
fonte: http://wirelessconnect.eu/articles/bandwidth%20_control 

Mikrotik - Tips and Tricks for Beginners and Experienced Users of RouterOS

fonte: https://wiki.mikrotik.com/wiki/Tips_and_Tricks_for_Beginners_and_Experienced_Users_of_RouterOS

Contents


This page contains various tips and tricks for RouterOS users, both beginners and experienced ones. Each subject depends on RouterOS version and might change from one version to another.


First steps of debugging and how to contact MikroTik support team

Very often major problems on network can be resolved in easy way. There is a presentation which shows simple first debugging steps and explains how to contact MikroTik support team if you have not managed to fix your problem by yourself.
Initial debugging steps in RouterOS

Firewall

Basic router protection based on connection state and IP address type by using Firewall

It is necessary to have proper firewall configuration on your routers to avoid different attacks and incorrectly formatted connections.
To do so, you can apply configuration (which of course should be modified for each users individual needs) which is show on example (written on 6.34.3 RouterOS),
In example WAN is gateway to internet, LAN is local interface and 192.168.88.0/24 is subnet used on LAN.
Create address list which includes different subnets (basically all subnets which should not exist in public network):
 /ip firewall address-list
 add address=0.0.0.0/8 comment=RFC6890 list=NotPublic
 add address=10.0.0.0/8 comment=RFC6890 list=NotPublic
 add address=100.64.0.0/10 comment=RFC6890 list=NotPublic
 add address=127.0.0.0/8 comment=RFC6890 list=NotPublic
 add address=169.254.0.0/16 comment=RFC6890 list=NotPublic
 add address=172.16.0.0/12 comment=RFC6890 list=NotPublic
 add address=192.0.0.0/24 comment=RFC6890 list=NotPublic
 add address=192.0.2.0/24 comment=RFC6890 list=NotPublic
 add address=192.168.0.0/16 comment=RFC6890 list=NotPublic
 add address=192.88.99.0/24 comment=RFC3068 list=NotPublic
 add address=198.18.0.0/15 comment=RFC6890 list=NotPublic
 add address=198.51.100.0/24 comment=RFC6890 list=NotPublic
 add address=203.0.113.0/24 comment=RFC6890 list=NotPublic
 add address=224.0.0.0/4 comment=RFC4601 list=NotPublic
 add address=240.0.0.0/4 comment=RFC6890 list=NotPublic
Create firewall filter rules to protect router from incoming (input) connections:
 /ip firewall filter
 add chain=input comment="Accept established and related packets" connection-state=established,related
 add chain=input comment="Accept all connections from local network" in-interface=LAN
 add action=drop chain=input comment="Drop invalid packets" connection-state=invalid
 add action=drop chain=input comment="Drop all packets which are not destined to routes IP address" dst-address-type=!local
 add action=drop chain=input comment="Drop all packets which does not have unicast source IP address" src-address-type=!unicast
 add action=drop chain=input comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic
Create firewall filter rules to protect your local network from passing (forwards) connections:
 /ip firewall filter
 add chain=forward comment="Accept established and related packets" connection-state=established,related
 add action=drop chain=forward comment="Drop invalid packets" connection-state=invalid
 add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface=WAN
 add action=drop chain=forward comment="Drop all packets from public internet which should not exist in public network" in-interface=WAN src-address-list=NotPublic
 add action=drop chain=forward comment="Drop all packets from local network to internet which should not exist in public network" dst-address-list=NotPublic in-interface=LAN
 add action=drop chain=forward comment="Drop all packets in local network which does not have local network address" in-interface=LAN src-address=!192.168.88.0/24

Block specific domains by using scripts

At the moment, it is not possible to block access for the specific domain on RouterOS. The only way to do it is to know IP addresses used by the domain and blocking them by using the firewall. The idea is - find out addresses, add them to address list and drop packets destined for these addresses. Since addresses usually are dynamic, you have to refresh them periodically. For such purposes, there is a script which will implement needed configuration. All you need to do is create scheduler which refreshes these addresses from time to time.
Example show how to block access to facebook.com and youtube.com (written on 6.34.3 RouterOS):
#Script to add IP addresses for specific domains to address lists
{
#Array of desired domain names
 foreach iplist in=("youtube","facebook") do={
  {
#Old entries are deleted
  /ip firewall address-list remove [find where list=$iplist]
#Dummy variable to not get into loop
  global counter true
#Check if IP addresses are not repeating themselves
   while ($counter) do={
#Resolve domain
    local ip [/resolve ("www.".$iplist.".com")]
#Add IP to address list under specific domain list if it does not already exist
    if ([len [/ip firewall address-list find where address=$ip]] = 0) do={
     /ip firewall address-list add address=$ip list=$iplist } else={
#If IP already exist in list then stop resolving this domain
     set counter false
    }
   }
  }
#If there is no firewall filter rules which blocks this specific domain then add it
  if ([:len [/ip firewall filter find where chain=forward && dst-address-list=$iplist]] = 0) do={
   /ip firewall filter add chain=forward action=drop dst-address-list=$iplist place-before=0 \ 
    comment=("This rule blocks access to " . $iplist)
  }
 }
}
Icon-note.png
Note: This will work only with IPv4 traffic


Ease load on firewall by sorting firewall filter, NAT and mangle rules

When a packet travels through the firewall it is checked against each rule until it matches one (except when passthrough action is used). It means that CPU load and packet processing speed depends on it. There is a very simple way how to ease the load on firewall filter, NAT and mangle rules - sorting. Based on the action, without breaking logical order, you should sort your firewall rules by checking packet count on statistics for each independent rule. Move rules which have more packets matched up and those who have been matched more rarely move down. Remember that you always have to be sure that logical order of rules is not affected by this sorting.

Ease load on firewall by using no-mark as a mark for packets, connections and routing

When a packet travels through the firewall it is checked against each rule until it matches one (except when passthrough action is used). If you use rules which have action mark-packet, mark-connection and mark-routing, then it is worth to set additional matcher as no-mark for the related parameter. It will allow for the firewall to decide sooner if the packet matches this rule and also will allow for you to avoid re-marking.
Example script which should configure router as explained before (written on 6.34.3 RouterOS):
foreach mrk in=("packet","connection","routing") do={
  {
    foreach i in=([/ip firewall mangle find where action=("mark-" . $mrk)]) do={
      local cmd ("ip firewall mangle set " . $i . " " . $mrk . "-mark=no-mark")
      :execute $cmd
    }
  }
}

Port forwarding on RouterOS

Port forwarding consists of three parts - forwarding in both directions and accepting packets in forward chain. All of these three parts must be correct in order to have working port forwarding configuration.
Lets use as an example public IP address x.x.x.x and local address y.y.y.y. Gateway interface name in example is "wan_interface".
Example should be adjusted for specific ports, addresses, interfaces and so on. Example only should be used to understand idea of port forwarding (written on 6.35.4 RouterOS):
1) NAT to local address (redirect all requests for x.x.x.x address to y.y.y.y):
/ip firewall nat add chain=dstnat action=dst-nat in-interface=wan_interface dst-address=x.x.x.x to-addresses=y.y.y.y
2) NAT from local address back to public IP (change source address to public IP for replies):
/ip firewall nat add chain=srcnat action=masquerade out-interface=wan_interface
or
/ip firewall nat add chain=srcnat action=src-nat src-address=y.y.y.y to-addresses=x.x.x.x out-interface=wan_interface
3) In case firewall filters are used to drop some traffic you must be sure that forward packets which belong to natted connection are accepted:
/ip firewall filter add chain=forward action=accept in-interface=wan_interface connection-nat-state=dstnat connection-state=established,related

Protect local network against attacks from public internet

Very often people use default configuration on their routers. That also means, that it is possible to guess which local address is used behind router. Usually it is 192.168.88.0/24 for devices which runs on RouterOS. This means, that in public network attacker can create simple route which says that 192.168.88.0/24 is behind your public IP and attack to your local network devices.
To protect your local subnet against these attacks very simple firewall filter rule can be used. This rule will drop all packets which are destined to local network but are not NATted. NATted connections are allowed because NAT is there for exactly this purpose - to allow/redirect access from public internet to local address.
Example script which should configure router as explained before (written on 6.34.3 RouterOS):
 /ip firewall filter
 add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface=WAN

Specify corresponding interface for firewall NAT rules

Very often you can see configurations where many firewall NAT rules are being used. Once you make one rule the whole principle is clear and you can easily add many of them. Quite often RouterOS users forget about interface parameter on these rules. Rules can work correctly without them but they also can turn out to be a cause of many different kinds of problems, for example, loops, lost access to internet and etc.
To avoid problems like these you have to always specify out-interface parameter for srcnat NAT rules and in-interface parameter for dstnat NAT rules. If you need to specify multiple interfaces, then you need to have multiple NAT rules. This all will also reduce load on CPU.
Wrong example (written on 6.34.3 RouterOS):
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.88.0/24
add chain=dstnat dst-port=1234 action=dst-nat protocol=tcp to-address=192.168.88.2 to-port=80
Correct example (written on 6.34.3 RouterOS):
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.88.0/24 out-interface=WAN
add chain=dstnat dst-port=1234 action=dst-nat protocol=tcp to-address=192.168.88.2 to-port=80 in-interface=WAN

General

Global variable is not working in script

In RouterOS there are many things which can be done by using scripts. Scripts and variables can be used in various places. Very often, for example, in Netwatch people define global variable and afterwards try to use it also in System/Scripts. Usually it does not work, because in very beginning of script you have to remember to define this variable by using command:
:global variable_name

If something does not work, then maybe it is like that on purpose

RouterOS has a feature called FastTrack. It makes connections even faster if it is enabled and correctly configured. When FastTrack is enabled, the traffic will bypass queues, firewall and other RouterOS features. When using FastTrack make sure that it is configured properly and does not interfere with other configuration. For more info see Manual:Wiki/Fasttrack page.
Icon-note.png
Note: As of RouterOS version 6.34.3 FastTrack only works with UDP/TCP IPv4 traffic. In most cases the configuration can be easily tested by using ping. If ping works and TCP/UDP does not, then it is very likely that FastTrack is enabled for this traffic.


Make sure that interface names are correct

Quite often after using different kinds of scripts or for any other reason interfaces on the router are renamed. If you are trying to configure something on the interface and it does not work as expected, make sure that you are trying to configure correct one.
Example command which should show correct interface names (written on 6.34.3 RouterOS):
[admin@MikroTik] > interface export 
/interface ethernet
set [ find default-name=ether3 ] name=ether1
set [ find default-name=ether1 ] name=ether3

Myth about the reboot

Very often people say that problem disappeared after the reboot. In most cases it actually is not true. Reboot does many things, for example, clears DNS cache, clears different dynamic entries and so on. If the reboot helped in your case, you should think what on your device is configured and what of it is cleared by the reboot. Then you can try to trace the real reason.

Throughput testing

Very often people are complaining about slow throughput through router. You have to understand that single stream test can use only one CPU core. For example, on CCR1009 you need 9 streams to utilise whole device. Also if you use Bandwidth Test, then test itself puts high load on CPU and results are worse than in a real life environment. Usually on RouterOS Traffic Generator with multiple streams should be used for throughput tests:
Traffic Generator manual
Traffic Generator usage examples

PPP

Create static bindings for PPP interfaces

If you do not like that your PPP interfaces are dynamic, then you can on PPP profile execute the on-up script which creates static server binding for each client.
Example is made for PPPoE interfaces, but it can be easily adjusted for any other PPP interface types (written on 6.34.3 RouterOS):
if ([/interface pppoe-server print count-only where user=$user && !dynamic] = 0) do={
  log info message=($user . " - is being added as static binding")
  /interface pppoe-server add name=$user user=$user service=service1
  /ppp active remove [find where name=$user]
}
Icon-note.png
Note: Last command within script will disconnect client at first time authentication


Queues

Limits specified on parent Simple Queue are not working

In RouterOS if you have Simple Queues with child queues, then you have to remember that after a parent queue matches some kind of traffic the same traffic will be again checked by the child queues. It means that you have to cover an entire set of packets which are captured by the parent and there is an easy way to do it by using the copy of the parent as a child.
Example which shows how to correctly create a child Simple Queue (written on 6.34.3 RouterOS).
This is not correct because only packets with address 192.168.88.2 will be limited by queues:
/queue simple
add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24
add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32
To fix this problem you have to add another child queue which would be a copy of the parent without specified limits:
/queue simple
add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24
add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32
add name=child2 parent=GLOBAL target=192.168.88.0/24

Queue slows down router

In the RouterOS, each Simple Queue works on single CPU core.
Example which shows how to ease the load on Simple Queue on multi-core systems (written on 6.34.3 RouterOS).
This queue will work on single core and will not work as fast as it would be possible:
/queue simple
add max-limit=100M/100M name=queue1 target=192.168.88.1/32,192.168.88.2/32
This queue will work on two CPU cores and will work better compared to previous queue (of course you have to be sure that limit is proper for you):
/queue simple
add max-limit=50M/50M name=queue2 target=192.168.88.1/32
add max-limit=50M/50M name=queue3 target=192.168.88.2/32

Basic guidelines on RouterOS configuration and debugging

Some of the basic RouterOS protection, configuration and debugging steps can be done in a easy way. Some of them are explained in this presentation:
Basic guidelines on RouterOS configuration and debugging
See also: https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router

terça-feira, 30 de maio de 2017

Mikrotik - link sobre problemas que devemos evitar nas configurações

https://mum.mikrotik.com/presentations/US17/presentation_4241_1496042977.pdf

segunda-feira, 29 de maio de 2017

Mikrotik - Using OSPF to create full duplex behaviour for wireless links


fonte: Using OSPF to create full duplex behaviour for wireless links

One reality that all WISPs face is that all radio communications are half-duplex.  When one end of a link is “speaking”, the other end must be “listening”.  For many applications, this is sufficient for our purpose.  When a link becomes busy, however, some types of communications are negatively impacted by the delays caused by this behaviour.  Mikrotik RouterOS offers some options to help you alleviate this congestion without breaking the bank. In this article, I will discuss the details for how to configure Mikrotik RouterOS and OSPF to provide a simulated full-duplex link with the added benefit of failover to half-duplex in the event of a single link failure.
This idea is taken from an article I wrote on my main website back in November of 2006.

Some of the advantages with this method include:
  1. It is full duplex (simulated)
  2. It will offer automatic failover in the event of a link failure (only one link – and losing this link will lose the full duplex “feel” of the link)
  3. It is VERY scalable
Use the following diagram as a reference:
The first scenario will be exactly as pictured. The four bridge radios can be ANY type of bridge device. They could be Mikrotik RB600 or RB411 with a single radio and configured as WDS bridged links or they could be 2 sets of Trango Tlink10s. For the purpose of this discussion, the bridges must be there, but what the specific equipment will only determine just how much bandwidth you will or will not have.  It is VERY IMPORTANT that the bridges pictured are true layer 2 bridges.
The basic idea is to create the links, then using OSPF path cost, cause the traffic from one side of the link to use link A and the traffic going the other way to use link B. If either link fails, the traffic will automatically failover and use the working link. I won’t discuss the configuration of the bridge devices, but they must be true bridges. (MT with WDS will work just fine).
Once you have the links in place, you will plug Link A into Router A on ether1, Link B into Router A on ether2 and the LAN side of Router A will be on ether3. The other side (Router B) will be done the same way. To understand how to set up OSPF, refer to Mikrotik’s documentation. You will add the following configurations to the indicated router:
Both routers:
/routing ospf network
add network=10.10.0.0/24 area=backbone
add network=10.10.1.0/24 area=backbone
Router A:
/routing ospf interface add interface=ether1 cost=100
Router B:
/routing ospf interface add interface=ether2 cost=100

This config will cause traffic from Router A lan side to use Link B (lower cost on ether2). Traffic from Router B will use Link A (lower cost on ether1). If either link fails, OSPF will automatically begin to use the working link.
If you wish, you can configure the same network using an RB600 (or other routerboard) with 2 wireless cards for Router A. The config is basically the same, except that what is shown as Bridge A and Bridge B would become wlan1 and wlan2. The configuration above would be changed appropriately (wlan1 = ether1).
An alternative method to accomplish a full duplex wireless link with Mikrotik is to use NStreme-dual.

sexta-feira, 26 de maio de 2017

Qual a diferença entre Velocidade de Navegação e Taxa de Transferência?


Para explicar de forma bem simples:

A Velocidade de Navegação é medida em bits por segundo. A Taxa de Transferência é medida em bytes por segundo.
1 byte = 8 bits.
Arquivos são medidos em bytes.
Quando contratamos o serviço de internet, os provedores indicam a velocidade em Megas. Falta informar que são MEGA BITS e não MEGA BYTES.
Portanto se você contratou um serviço de internet de 10 Megas, a velocidade máxima que conseguirá para baixar um arquivo será de 1,25 Mega Bytes por segundo. Nesse caso, se você for fazer o download de um arquivo que tenha 5 MB (5 Mega Bytes), poderá baixá-lo em 4 segundos, NA MELHOR DAS HIPÓTESES.
Então, Velocidade de Navegação é o termo utilizado comercialmente pelos provedores. O que importa é a Taxa de Transferência.
Como fazer rapidamente a conta da diferença: divida a velocidade informada pelo provedor, por 8.

terça-feira, 23 de maio de 2017

Raspberry - Novo kit permite transformar Raspberry Pi 3 em um mini PC com SSD



Fabricado pela varejista Element 14, o novo Pi Desktop será lançado nos EUA em 5 de junho por US$56 dólares e exige conhecimento técnico para ser montado.
Autor da Foto
A varejista do Raspberry Pi, Element 14, recentemente anunciou um nov kit de mini desktop interessante para o Raspberry Pi 3 chamado de Pi Desktop. O conceito geral é parecido com o NUC, da Intel, mas com menos poder computacional e muito mais “faça você mesmo”. O kit aproveita o poder do Raspberry Pi e adiciona alguns recursos extras, como uma interface mSATA para um SSD. 
O Pi Desktop será vendido por cerca de 56 dólares quando for lançado nos EUA no próximo dia 5 de junho.
O kit em si traz uma placa add-on que se conecta por meio da GPIO de 40 pinos do Raspberry Pi. A placa traz a interface mSATA, um controlador de energia, e um clock do sistema. Além disso, o kit oferece o case, um adaptador USB, um dissipador de calor, a bateria da placa, e espaçadores e parafusos suficientes para montar seu minúsculo PC desktop Raspberry Pi. 
pidesktop_62502.jpg
Uma vez que você tiver o kit, precisará adicionar sua própria Raspberry Pi 3 e um SSD de até 1TB – a Element 14 afirma que você pode fazer a inicialização diretamente a partir do SSD. A Raspberry Pi em si oferece a maioria dos recursos computacionais necessários para o seu novo mini PC, incluindo quatro entradas USB, Wi-Fi, Bluetooth, ethernet e saída HDMI. 
O impacto na sua casa
O Pi Desktop não é para todos os usuários, já que exige conhecimento técnico para ser montado e utilizado, mas definitivamente adiciona um pouco mais de estilo e conveniência ao PC home theater baseado no Raspberry Pi 3.

sexta-feira, 12 de maio de 2017

Mikrotik - script to set channel list

Usem com cuidado, pois nem todos canais são permitidos em determinados países.
 #Script to set channel's in list.
#Will do both 10 and 20mhz in 5ghz

:global ifslink 5180,5750,5770,5790,5810,5830,5850,5870,5890
#Set 5ghx 20mhz scanlist
:global ifs5ghz 5390,5410,5430,5450,5470,5490,5510,5530,5550,5570,5590,5610,5630,5650,5670,5690
#set 5ghz 10 mhz scanlist
:global ifs2ghz 2409,2429,2414,2434,2419,2439,2424,2444,2449,2469,2454,2474,2459,2479,2464,2484
#set 2.4 ghz scanlist
:global band5ghz 5ghz-a/n
#possible values 5ghz-a  5ghz-a/n  5ghz-onlyn
:global band24ghz  2ghz-b/g/n
#possible values 2ghz-b  2ghz-b/g  2ghz-b/g/n  2ghz-onlyg  2ghz-onlyn

:global ifw5ghz20 20
:global ifw2ghz 10
:global ifw5ghz10 10


:foreach i in=$ifs5ghz do={/interface wireless channels add list=5ghz-10mhz frequency=$i width=$ifw5ghz10 band=$band5ghz } 
:foreach i in=$ifslink do={/interface wireless channels add list=5ghz-20mhz frequency=$i width=$ifw5ghz20 band=$band5ghz } 

#for 2,4ghz#
# :foreach i in=$ifs2ghz do={/interface wireless channels add list=2ghz-10mhz frequency=$i width=ifw2ghz band=band24ghz }

Mikrotik - Channel List (for CAPsMAN)

Quick-N-Dirty List for 2,4 GHZ: 
/caps-man channel add band=2ghz-b/g/n name=CH1 frequency=2412
/caps-man channel add band=2ghz-b/g/n name=CH2 frequency=2417
/caps-man channel add band=2ghz-b/g/n name=CH3 frequency=2422
/caps-man channel add band=2ghz-b/g/n name=CH4 frequency=2427
/caps-man channel add band=2ghz-b/g/n name=CH5 frequency=2432
/caps-man channel add band=2ghz-b/g/n name=CH6 frequency=2437
/caps-man channel add band=2ghz-b/g/n name=CH7 frequency=2442
/caps-man channel add band=2ghz-b/g/n name=CH8 frequency=2447
/caps-man channel add band=2ghz-b/g/n name=CH9 frequency=2452
/caps-man channel add band=2ghz-b/g/n name=CH10 frequency=2457
/caps-man channel add band=2ghz-b/g/n name=CH11 frequency=2462
/caps-man channel add band=2ghz-b/g/n name=CH12 frequency=2467
/caps-man channel add band=2ghz-b/g/n name=CH13 frequency=2472
 
5Ghz: 
/caps-man channel add band=5ghz-a/n/ac name=CH36 frequency=5180
/caps-man channel add band=5ghz-a/n/ac name=CH40 frequency=5200
/caps-man channel add band=5ghz-a/n/ac name=CH44 frequency=5220
/caps-man channel add band=5ghz-a/n/ac name=CH48 frequency=5240
/caps-man channel add band=5ghz-a/n/ac name=CH52 frequency=5260
/caps-man channel add band=5ghz-a/n/ac name=CH56 frequency=5280
/caps-man channel add band=5ghz-a/n/ac name=CH60 frequency=5300
/caps-man channel add band=5ghz-a/n/ac name=CH64 frequency=5320
/caps-man channel add band=5ghz-a/n/ac name=CH100 frequency=5500
/caps-man channel add band=5ghz-a/n/ac name=CH104 frequency=5520
/caps-man channel add band=5ghz-a/n/ac name=CH108 frequency=5540
/caps-man channel add band=5ghz-a/n/ac name=CH112 frequency=5560
/caps-man channel add band=5ghz-a/n/ac name=CH116 frequency=5580
/caps-man channel add band=5ghz-a/n/ac name=CH120 frequency=5600
/caps-man channel add band=5ghz-a/n/ac name=CH124 frequency=5620
/caps-man channel add band=5ghz-a/n/ac name=CH128 frequency=5640
/caps-man channel add band=5ghz-a/n/ac name=CH132 frequency=5660
/caps-man channel add band=5ghz-a/n/ac name=CH136 frequency=5680
/caps-man channel add band=5ghz-a/n/ac name=CH140 frequency=5700
/caps-man channel add band=5ghz-a/n/ac name=CH149 frequency=5745
/caps-man channel add band=5ghz-a/n/ac name=CH153 frequency=5765
/caps-man channel add band=5ghz-a/n/ac name=CH157 frequency=5785
/caps-man channel add band=5ghz-a/n/ac name=CH161 frequency=5805
/caps-man channel add band=5ghz-a/n/ac name=CH165 frequency=5825