Mikrotik QOS in distributed systems or smart shapers
And what would you have to offer?
- What is there to offer ... And then they write, they write ... the congress, the Germans are some ... The head swells. Take everything and share.
“So I thought,” exclaimed Philipp Philippovich, slapping his hand on the tablecloth, “and thought so.”
M. Bulgakov, "Heart of a Dog"
About the division of speed, prioritization, the work of the shaper and everything else is already a lot of things written and drawn. There are many articles, manuals, schemes and other things, including the materials I have written. But judging by the increasing flow of letters and messages, reviewing previous materials, I realized that some of the information is not as detailed as necessary, the other part is simply outdated and just confuses newcomers. In fact, the QOS on microtic is not as complicated as it seems, but it seems difficult because of the large number of interrelated nuances. In addition, it can be emphasized that it is extremely difficult to master this topic, guided only by theory, only by practice, and only by reading the theory and examples. The main crutch in this case is the lack of a visual representation in Mikrotik of what is happening inside the PCQ queue, and what cannot be seen and felt must be imagined. But the imagination of all is developed individually in one degree or another.
Therefore, I decided to write another material in which I will mix theory with practice, visual examples and break this material into blocks from simple to complex. With each new example, I will add the necessary information, and at the very end you will get a complete picture of how it all works. I think that it will be much easier to understand the basic principles of building a shaper on microtic.
In this article, I will only consider Queue Tree queues using PCQ. Excuse me, Simple Queues for me is somewhat a wrong level of opportunity. Also, outdated material will not be described, which is applicable only to the fifth versions of ROS, although in some moments I will refer to it for comparison.
')
We have a microtic:
WAN interface with white address (1.1.1.1) and an incoming speed of 32 megabits per second
LAN - with subnet 192.168.0.0/24
The task is to cut the incoming speed in various combinations (Download) for the subnet 192.168.0.0/24. We will not touch the outgoing speed (Upload) for the time being, but I note that its implementation is almost the same as the input speed.
In order to cut something in the microtic we must determine the criteria for selecting the traffic we need and select it. For this we need / ip firewall mangle.
Mangle can be represented as a kind of filter that can take packets and connections from a general stream according to certain criteria and perform certain actions with them.
Our only criterion is known: from the general flow, we only need packets that go to the 192.168.0.0/24 subnet. As an action with these packages, we will select the assignment of a label to the package, later on the basis of this labeling the packages can be processed in the Queue Tree.
In order to properly mark a package, you need to know which chains it passes in Mangle. To do this, you need to know the movement diagrams of the packets (Packet Flow) and not anyhow what, but fresh diagrams because in the sixth version of the ROS scheme has changed slightly. And naturally, having looked at these diagrams for the first time, you will have nothing but swear words on your lips.
Again, not everything is as difficult as it seems, these diagrams show how traffic flows in all cases, but we will need only a small part of them to work with the shaper.
Based on this diagram, you can understand that the traffic of interest to us is on the way:
Input Interface> PREROUTING -> FORWARD -> POSTROUTING -> Output Interface
The scheme with NAT enabled will be a little fatter:
Input Interface> PREROUTING> DST-NAT> FORWARD> POSTROUTING> SRC-NAT> Output Interface
Which chain to choose?
In the fifth version of ROS, besides where NAT is located, it was also necessary to know where the processing of the global-in, global-out and global-total queues are.
In the sixth version it became easier, because The above treatments were abolished and replaced with one global. And this global is at the very end of POSTROUTING, after it the queues of SimleQueue are processed and the packet is released at will. Based on this, it does not matter to us where he is now, since all marking treatments are made before it.
And if so, then the only restriction we create is only NAT, and the choice will depend on the direction of traffic that we want to mark. On this occasion, I added my own diagram:
As can be seen from the diagram, in order to label received packets, we need chains in which gray subnet 192.168.0.0/24 (dst-address) addresses are available.
And you can see them only in FORWARD and POSTROUTING.
In order to mark the Upload packets, chains are needed from the second half of the diagram, in which gray subnet 192.168.0.0/24 addresses are available (src-address).
And they are available in all three chains PREROUTING, FORWARD, POSTROUTING.
I am glad that I was not lazy and wrote so many extra books. And all in order to convey to you the information that, regardless of the direction we want to mark, you can choose the FORWARD chain in both cases. But this can not be done in the fifth version of ROS.
We decided on the chain, now we need to decide how we will tag the packages. First mark the connections, and only then mark the necessary packages in them? Or just mark the packages and everything will fly up?
Some time ago, during the time of the first versions of the sixth line, one good person wrote to me (for which I thank him so much!), And said that he had an interesting glitch in his system. He gave me a connection to TeamViewer and showed how the usual marking of packages marks a third (third! Karl!) Of packages more than marking with the same parameters but within the limits of connections. Accordingly, the speed in the tree was normal, but on the interfaces were a third higher. Tinkering for a long time, found nothing. I did the second marking according to the same criteria outside the connection, having previously disabled further transfers of already marked packets in the higher rules. All this is logged. Normal normal packages, why they did not fall into the connection did not understand.
I put the same version on my test bench (one WAN, one LAN and all this under double NAT) set up the rules and caught the same bug in my room. For four or five (no longer remember) versions, I caught this glitch. Then he stupidly did a load test and realized that the load on the stone was not so great as to use markings in the joints. Since then, on the labeling of packages in the connections - I scored. As hands reach - I will check, but for now I label the packages like this.
By this rule, we mark all packets for which the dst-address is equal to the address to the “LAN” sheet, and we also assign them a “LAN” to the packet-mark.
Also add the address list itself:
In this direction, marking in one direction is completed, in order to mark outgoing traffic, we need a copy of the rule, where dst-address-list = LAN is replaced by src-address-list = LAN
But as I wrote, for example, we take only incoming traffic.
In order to create a PCQ queue in this case, one rule and a profile in the Queue Type are required. But I will create two rules in order to show in one example how the queue behaves in either way or another when setting limits.
Parent turn
There are a few points to clarify:
parent = global - In this parameter, you can specify either "global" or the name of the interface. The interface name here plays the role of a specific traffic direction filter and is used in complex configurations to exclude all directions except the specified interface and is valid only for this queue and its descendants. Always specify in this parameter “global” the effect will be the same, and there will be less problems.
max-limit = 30M - in the statement of the problem it is indicated that the channel gives us 32 meters, but you need to register a little less than the available speed. Otherwise, you will run into the shaper of your provider, yours just will not work.
burst-limit = 0 burst-threshold = 0 burst-time = 0s - disabled because their use does little for PCQ, but in the profile they are of sufficient relevance for use.
priority = 8 is the priority of the queue, 1 is the highest priority, 8 is the lowest priority. DOES NOT WORK if the queue has children.
Priorities work only among descendants, and they compete with each other not only within their parent, but also with the descendants of other parents, and only in the case of a common grandfather who limits the speed of these parasites. With the same priorities, they will distribute among themselves all the speed available to the grandfather. If they are different, they eat first priority ones from a common grandfather's bowl, then those who have a lower priority eat it, and then only if something remains, well, or the parents spread their grandfather to Limit-at. Although parents can arrange a battle of titans among their descendants, if they have not only Limit-at installed, but Max-limit as well. It will be in style: “do not devour everything, the grandfather has other children with grandchildren from their first marriage!”
Well yes postebalis and enough! I’ll tell you about the limits and priorities more clearly later.
In general, we created a parent, now he needs a descendant. But to add a child (the final queue), you must first add a profile. We add.
kind = pcq - Indicates that the queue that uses this profile is the initiator of the PCQ subkeys
pcq-burst-rate = 0 pcq-burst-threshold = 0 pcq-burst-time = 10s - Burst Speed ​​Settings, more on that later.
pcq-classifier = dst-address - This parameter indicates by what classifier PCQ queues will be created. In this case, to the destination address (incoming traffic)
pcq-dst-address-mask = 32 and pcq-src-address-mask = 32 - set the number of addresses in one queue. (32 = one queue for one ip address)
pcq-rate = 0 - Sets the upper speed limit for one PCQ queue (in our case for one ip address) If zero is specified, the speed is unlimited and will be divided equally between queues (ip addresses). In our case, 30 megabits will be divided equally between the active queues (ip addresses).
pcq-limit = 50 - the limit of the size of one queue (for one ip address) All data in this queue is delayed when the limits are reached, all that does not fit into it is destroyed.
pcq-total-limit = 2000 - limit the size of all queues.
Now that we have a parent queue and a child profile, we will add the child itself:
packet-mark = LAN - here we catch in a queue a stream of packets marked in the mangle.
parent = DOWNLOAD - indicated the parent who limited our speed.
queue = PCQ_DOWNLOAD_LAN - refer to the profile with settings in the Queue Type
Well, that's finished with the rules. Let's look at the visual chart.
Everything that happens at the top, you already know, further mixed labeled packets in a chaotic manner, are picked up by a queue by a child. And here the most interesting begins.
Suppose we now have three machines in the subnet: 192.168.0.1, 192.168.0.2 and 192.168.0.3.
Due to the fact that the descendant is tied to a profile with the name “PCQ_DOWNLOAD_LAN”, the profile was told to him: that it is necessary to create a separate PCQ queue for each address encountered in the marked dst-ip address.
We will have three PCQ queues (streams) inside the Queue Tree queue with the same pcq-rate, pcq-limit parameters and Burst speed settings.
In this case, the queue worked as a kind of packet sorter. And for each user created an individual queue.
Each queue goes through pcq-rate, it is this thing that holds packets in individual queues.
Next, the packets are mixed and arrive at the second part of the Queue Tree queue with the name “LAN”, where they are tested for the Max-Limit total speed, if it is exhausted, then this Max-limit will be divided equally between PCQ queues (streams) the delay is at the pcq-rate level, some queues are accelerated, some are slowed down. Anything that doesn't fit into pcq-limit is destroyed.
But we have not established this parameter in the “LAN” queue and therefore the traffic creeps up to the parent queue (DOWNLOAD). There everything happens by analogy, Max-Limit is checked and if it is reached - the parent queue kicks the pcq-rate to close the drawbar. Flow rates are aligned, and everything returns to normal.
Imagine for a second that we have not set Max-Limit in the parent queue. So, if no Max-Limit value was detected anywhere along the traffic path with pcq-rate = 0, then the whole queue will not work, all traffic will pass through the shaper without delay, since There is no one to tell pcq-rate that the channel is not rubber.
Many are tormented by the question if in this case pcq-rate = 0, there are three users, two are sleeping, and one is pumping. Does he live all 30 megabits? - Yes!
And what will happen if another one wakes up and starts pumping too? - Rebuild and alignment of speeds will be made. 30 megabits they share equally. The only caveat - it takes time, the second user will be a little slower to pick up speed than usual.
The essence of the mechanism is to delay and destroy packets that did not fit into the limit. The TCP protocol is designed in such a way that, within the framework of the connection, the server that sends data to the client, checks how it got to it, if the packets have increased latency or the packet is lost (sequence irregularity), the server lowers the sending speed to increase stability.
pcq-limit and pcq-total-limit are set experimentally, the greater the limit, the greater the delay and the more memory the router uses. The lower the limit, the more packages will be destroyed.
What happens if pcq-rate = 5M?
Each user will receive no more than 5 megabits. 3 active users * 5 megabits = 15 megabits.
Three active users, everyone downloads in full, pcq-rate = 11M?
The speed will rest on the Max-limit of the parent queue (30M) and this speed will be divided among users evenly by 10 megabits. If one of them leaves the download or slows down to at least 8 megabits, the other two will accelerate to 11 megabits.
I really hope that, according to this example, everything is clear, if it is not clear - read it again and again, then it will be more difficult.
Burst technology is designed to supply increased speed at a designated limit for a short time. It is advisable to use this feature at low-speed tariffs, to speed up web surfing or quickly upload data to applications. This function only works if pcq-rate is non-zero.
I will not load you to the blue in the form of graphs and formulas for calculation, I’ll better give an example.
Pcq-rate = 2M
pcq-burst-rate = 4M
pcq-burst-threshold = 1M
pcq-burst-time = 10s
The maximum user speed is 2 megabits. If the speed of its operation at the moment is less than 1 megabit (pcq-burst-threshold), the speed of 4 megabits (pcq-burst-rate) for 10 seconds (in practice less) will be available to pcq-burst-time. The counter starts ticking from the moment when the threshold of 1 megabit (pcq-burst-threshold) is exceeded, after a time the speed drops to pcq-rate so that Burst becomes available again - the user's speed should fall below 1 megabit and be there at least 10 seconds (pcq-burst-time)
It is clear that this is a very rough explanation, in fact, the time of availability of the burst is calculated by a complicated algorithm - the time is divided into 16 segments and taking into account almost all variable speeds and limits, the time of action is calculated.
This function consumes a significant amount of resources, use it wisely.
For reference: When making any changes, in any queue and in any of its manifestations (Tree or Simple) - all counters are reset, including and burst counters. If you use scripts to automatically correct Max-Limit values ​​of the QOSEvxController type - be prepared to abandon the Burst or use the queue check cycles in the QOSEvxController not so often.
Just recently, in the sixth version of ROS for queues, a new parameter bucket-size (bucket size) has appeared. This parameter can be changed from 0.1 to 10 and is used to set the capacity of the bucket with tokens. Bucket capacity is calculated by the forum:
Capacity in megabytes = bucket-size * max-limit
A bucket withhomogeneous tokens hangs over each queue until the traffic in this queue exceeds the limit (max-limit) tokens are accumulated in this bucket. When the bucket overflows, the token that falls into the full bucket is destroyed.
What tokens are spent on.
In this example, the capacity of the bucket will be: (max-limit = 10M) * (bucket-size = 10) = 100 megabytes
If the user or users of the packet stream labeled “PC1-traffic” did not download anything at full speed until recently, the bucket with tokens in this queue will be full, and this will be as much as a hundred megabytes of traffic. And so they decided together, to swing something, and so, they will receive the first 100 megabytes of traffic without a speed limit on max-limit, when 100 megabytes will be downloaded and the queue will start to limit the speed according to the specified max-limit = 10M.
In addition, if the queue has a parent with a bold max-limit, then after the descendant has exhausted all of its tokens, it will begin to take tokens from the parent queue from its bucket.
What is it for?
Bucket-size is like a kind of burst, but not in terms of speed but in terms of traffic volume. Using it in conjunction with the PCQ queues will give only doubtful benefits. In single pfifo, red and sfq seed drills can be extremely useful. For PCQ queues, the only thing that comes to mind is that we limit the speed of the parent queues, which is slightly lower than the actual speed of the channel. Proper use of this function can more quickly exploit the full available channel speed and smooth out user activity peaks.
More detailed bucket job diagram:
In this example, I indicated that we have one subnet (192.168.0.0/24) with three users (192.168.0.1, 192.168.0.2, 192.168.0.3). We marked traffic to these addresses with one rule in mangle and one address list.
Just in case, I will say that for mangle there is no difference, as we will feed him the addresses to be marked - they will be processed in the same way.
Subnet entirely:
Address Range:
Individual addresses:
The situation is similar with PCQ queues. A PCQ queue without problems parses one packet flow, marked by a single rule, consisting of addresses of different subnets on the sub-queue.
Suppose that we mixed three more users from another subnet (192.168.1.1, 192.168.1.2, 192.168.1.3). Just by adding the necessary entries to the address list. Then we get the following picture:
Based on all of the above, we can conclude that we operate not with subnets, but with groups of ip addresses that we create using address lists
In this case, it makes no sense to separately mark traffic, make two profiles and two queues.
This approach is necessary only in the following cases:
When you need to set an individual Max-Limit for the selected address group.
When a different priority is needed for address groups or traffic types.
When the implementation of various tariff plans for a group of addresses. (pcq-rate)
And in all possible combinations of the above cases.
Here is an example of how not to do it:
Full listing example:
Suppose we are an organization administrator with a small number of employees.
We have the initial data:
WAN interface with white address (1.1.1.1) and an incoming speed of 32 megabits per second
LAN - with subnet 192.168.0.0/24 (Workstations of Directors)
LAN2 - with a subnet 192.168.1.0/24 (Workstations Managers)
In this example, we just have one channel and two groups of consumers with different priorities. Where directors take precedence over managers. In this case, for the implementation of this scheme will require separate labeling of packages and separate queues for user groups.
Marking Rules:
Two rules for marking traffic with different packet-mark and two lists for assigning group membership addresses.
It's time to create PCQ profiles for queues.
How many profiles are needed? In theory, one profile will be enough for downloading, but I always create a separate profile for each group and for each direction. This allows you to have flexible settings for the future, without additional intervention in the already created rules and queues
Create a queue tree:
Parent queue:
Descendants:
In this example, there is nothing difficult, the difference between the queues only in different package markings and different priorities.
At low speeds, this scheme will transparently pass traffic through itself and any consumer can receive all 30M specified in the parent queue.
If there is a lack of speed in the parent queue, the speed will begin to be redistributed among consumers according to the following scheme:
The group with addresses GROUP-A_DW has a higher priority (priority = 7), it will be given the entire speed of the parent queue (30M) and is evenly divided between active consumers within this queue.
If this group has not utilized the entire available speed limit (30M), the remainder of this limit will be transferred to the queue with a lower GROUP-B_DW priority (priority = 8), where these residues will be evenly divided among active consumers within this queue.
If GROUP-A_DW has scrapped the entire available 30 megabit limit, GROUP-B_DW will not receive any speed at all and no opportunity to send and receive packets from the network.
In order for a group with a low priority to have at least a certain amount of speed, you can set the limit-at = 5M parameter in the queue. But this parameter can only be set together with the Max-Limit parameter, we do not need to limit the maximum speed of the group - so we just copy it from the parent queue.
And the second turn after the edits will look like this:
In such a case, if there is a shortage of speed in the parent queue, the low priority queue will always receive at least 5 megabits, which it can evenly divide between active consumers within this queue.
In this example, a kind of hybrid will be considered, which includes implementations from the first two examples.
Suppose we are a subprovider with limited financial and technical capabilities. We have a narrow channel on the Internet, a couple of tariff plans and two categories of subscribers (individual and legal person). Most often, when providing services to legal entities, we get more benefits from them than from individuals at the same rates of speed. At the same time, we provide legal entities with some additional guarantees in the form of guaranteed speed and more operational technical support.
Well, as often happens - we got a little carried away and hooked up a little more subscribers than our channel can pull into the Internet. On the right - you need to expand the channel or connect an additional one with subsequent load balancing. But as already mentioned, this is not yet possible.
But there is not enough speed at prime time, legal entities are starting to call and complain about speed, packet delays, telephony stuttering, etc., which are inconsistent with the tariff plan.
The shaper with priorities as in the second example will help to partially alleviate this situation, the only differences are that in this example the speed per subscriber is strictly limited and there are several tariff plans.
As in the previous examples, we consider only the incoming speed. However, to avoid confusion in comments, label names and queue names, upload speed will be present.
Abbreviations:
FIZ - an individual.
UR - a legal entity.
1024K-1024K - Speed ​​by rate: Download-Upload
DW- Download
UL - Upload
Package marking:
Four marking rules that will give us four streams of tagged packages sorted according to four tariff plans (Two for individuals and two for legal entities)
To bind a subscriber to a specific tariff plan, you need to put his ip address in the desired address list:
Etc.
Now you need to add the necessary profiles for the queues:
Again, I created four profiles instead of two, to preserve the flexibility of settings for the future.
Next, build the queue tree:
Parent queue:
Descendants:
When implementing this example, everything will work as follows:
At low speeds, subscribers without problems get their tariff rate, which is limited by the pcq-rate parameter.But the most interesting thing begins when there are more active subscribers than a channel can produce.
The parent queue is limited to 30 megabits.
Tariff plans of individuals and individuals themselves are equal.
Tariff plans of legal entities and legal entities themselves are equal among themselves.
But due to the fact that the queue of legal entities has a higher priority, it follows that the legal entities themselves with their tariff plans also have a higher priority - and they will be processed first.
All available speed is given in tariffs for legal entities, each such subscriber is limited by the rate of the tariff specified in the pcq-rate parameter. However, if these subscribers work intensively and their traffic consumption exceeds 30 megabits in total, we get the following picture:
30 megabits will be divided equally between legal entities, based on the current number of packets in each PCQ queue. In fact, it is not so easy to explain this situation, but I will try.
Suppose that all of the listed legal entities in our country swing “to the fullest”. At the moment there are four subscribers with a tariff of 1 megabit and twelve subscribers with a tariff of 3 megabits.
4 * 1M = 4 megabit
12 * 3M = 36 megabit
4M + 36M = 40 megabit is required for subscribers with the same priority.
But we have only 30 megabits. Everything would be just in the case of the same tariff plans: 30 megabits would be equally divided between subscribers and that's it. But how will the speed be distributed if our tariffs are different within the same priority group?
How will the lack of speed be distributed?
Two scenarios come to mind, but only one of them is correct.
The lack of speed will be distributed as a percentage based on the speed of the tariff plan. Something like this:
(100% / 40 megabits which are required) = 2.5
30 30 megabits which are * 2.5 = 75% of what we need.
(1 megabit / 100%) * 75% = 0.75 megabits
(3 megabits / 100%) * 75% = 2.25 megabits
Check:
4 subscribers with a tariff of 1M (4 * 0.75) = 3 megabits.
12 subscribers with a tariff of 3M (12 * 2.25) = 27 megabits.
27 + 3 = 30 megabits.
In principle, it is logical and relatively honest, but unfortunately this scenario will be handled a little differently, namely:
All available speed (30 megabits) will be distributed evenly between the participants in equal units of time.
Imagine a vat with 30 liters of water, from which pipes of the same cross section and N are the number of glasses of different sizes on the table, into which a limited volume of water is simultaneously poured in equal streams. In our example, the smallest glass has a volume of one liter, a bigger glass - three liters. (Three liters! Karl!) As soon as the small glasses are filled, they stop pouring water. All remaining water will continue to be poured into larger glasses. If after this the water in the vat remains, it will be poured into glasses on another low-priority table. But water, we do not even have enough for one table.
Complicated calculations:
First stage, first time interval:
4 cups per liter = 4 liters
12 glasses of three liters, but this time interval is filled with only liter = 12 liters.
30 liters - (4 + 12) = 14 liters of water left in the tank.
The second stage, the second time interval:
Due to the fact that there are no glasses of more than three liters in the example, we simply divide the remaining water between the three-liter glasses.
14 liters / 12 glasses = 1,1666666666666666666666666666667
Total calculations: The
user will receive the entire megabit at a rate of 1 megabit.
A user at a rate of 3 megabits will receive 1+ 1.16 = 2.16 megabits.
Same thing if you use simple calculations:
(30 liters - 1 liter * 4) / 12 = 2.16
If you look closely at both examples (incorrect and correct), you can see that in the first example, the total lack of speed on the tariff for all is exactly a quarter of the declared speed and all tariffs suffered the same way. In the second case, small tariff plans did not feel the shortage and received the declared speed, however, the tariffs with a higher speed felt a shortage of almost a third.
Based on the unduly outlined and not the most successful metaphor, we can conditionally say that tariffs with low speeds have a certain priority over tariffs with higher speeds, with a lack of speed, even with the same priority.
Yes, this is not entirely fair, but, unfortunately, this behavior of the shaper cannot be changed.
Here at this moment the point of view of Mr. Sharikov abruptly went out.
Not everyone will suffer evenly, but only those who have a more cheerful tariff plan. Well, as usual, the more speed - the more the subscriber pays. If this situation is even more or less permissible with individuals, then with legal entities it cannot even be called an annoying misunderstanding.
Well, let's return to the further discussion ...
Under these conditions, it can be seen that a channel of 30 megabits is not enough even to service the tariff plans of legal entities. Therefore, while legal entities intensively receive data, individuals do not receive any speed at all. This problem can be solved by setting the limit-at parameter, but in this case it will further reduce the available speed for legal entities.
It is clear that such a situation in reality will be equal to disaster. But we will push the disaster away and imagine that there are not so many legal entities. Namely: 2 with tariffs of 1 megabit and two with tariffs of 3 megabits. And they swing "to the fullest."
By simple calculations (2 * 1 + 2 * 3 = 8, 30-8 = 22), we understand that after servicing legal entities, the queue of individuals will reach only 22 megabits and they will be divided between them according to their tariffs. If there are too many individuals and this speed is not enough for them, the division will start as in the above described case with a large number of legal entities.
But no matter how fast individuals have enough speed, legal entities will be served first.
In addition to the classical system of priorities, when the flow is divided into several groups of subscribers with different priorities, you can tie additional criteria for the division of priorities.
On this subject, you can argue for hours. Some people will say that under special circumstances, it is certainly worth using priorities. And, of course, they will provide weighty arguments in favor of these decisions. Others will start shouting about performance and how ethical this solution is - they say who we are to decide for the user or subscriber what type of traffic is more important to him.
I never got into this stupid holivar. Just in view of the great experience I have my own point of view on this matter. It all depends on each specific case and type of application of this technology.
, — , , , (. — icmp). , , .
There are also a lot of examples where these solutions have found their place and have significantly improved the work of the network and the reputation of these sub-providers. In some cases, it seemed that the use of prioritization in a particular case was unjustified (wide channels, everything is enough for everything and this feature simply loads the processor), however, with four outlines from the heap out of six, the speed was sorely lacking. And this supposedly unnecessary feature has greatly reduced the number of calls to technical support. Yes, the speed of downloading torrents significantly slipped; nevertheless, there were no complaints from “tankers” about the long ping and lags in the game.
In addition to all this, those people who have more experience know that the word prioritization means a very broad topic and various uses. I think it is worthwhile to list the main types:
The user thread is divided into two, with different priorities. The separation criteria can be ports, protocols, destination addresses, source addresses, and entire subnets.
Performance for high priority is achieved by allocating additional speed bandwidth in excess of the subscriber rate and a higher priority queue. Thus, the subscriber receives the rate of the tariff under the high priority + the rate of the tariff for the rest of the traffic. In fact: the subscriber receives the tariff rate multiplied by two. In practice, with free uplink and full use by the subscriber of their speed at the rate, the subscriber, on average, uses the rate of the tariff + 20%. If there is a shortage of uplink, low-priority traffic is delayed (the band is narrowed), high-priority traffic is passed (a separate band with a higher priority).
The user thread is divided into two, with different priorities. The separation criteria are usually subnets. In one stream, external traffic goes to the world, in the second, internal or inter-subscriber traffic. It is used extremely rarely, usually in distributed systems consisting of several routers.
Almost not used in wired networks. Wireless network administrators know that with one-way data transmission via radio equipment (simplex), the speed is several times higher than in the presence of counter traffic (duplex). Most often, if there is oncoming traffic, more than 30% of the link is highly degraded.
For example:
UDP test on UBNT bridges via AirOS
simplex ~ 130-160 megabit / s.
Duplex ~ 40-50 megabits / c.
In the sixth version of ROS with its changes (the global root queue and forward mark), it became possible to control duplex traffic with restriction and decrease in the priority of outgoing traffic from subscribers.
This theory mainly relates to B / G / N, when using equipment operating in AC mode, the counter traffic is not so bad.
Well, well, the theory and the basics are clear. There is a real task to make some smart shaper. Where to begin?What factors should be considered in order not to collect all the rakes and subsequently not to redo everything all over again?
Before you create some design, the shaper must first be determined with a variety of parameters that your network has, or will have in the future. If you do not do this now, then in the future there may be problems that will force you to rework the structure from scratch. It is also worth remembering that each new function, requirement or criterion will cost processor time. Most often, this cost will increase exponentially. Therefore, think twice about how critical and appropriate this function is in your configuration.
The first thing we start with is the channels on the Internet.
The first thing you need to pay attention to is the number of channels. If you have several channels on the Internet or only plan to use several channels in the future, then most likely you will need to make a unique shaper for each channel.
I'll explain why.
When creating a common shaper, you will need to set the max-limit value in the root queue, which will be equal to the sum of the speeds of your channels. In theory, this will work, but in practice, not everything is as fabulous as it seems.
First, no matter how cool the load balancer between the channels is between the channels - there will always be a certain imbalance. Different load on the channels of at least 1% will disrupt the stable operation of the shaper and at least 1 subscriber on each channel will receive less of the tariff rate.
Secondly, the speed of some channels may “float” from time to time and as part of the balancing this will lead to a crash. Neither the balancer nor the shaper will know about the real uplink speeds. And even an artificially created supply of capacity in this case will not save.
Third, if one of the channels drops, the total capacity will change, and the max-limit value in the queue will become irrelevant. As a result, the shaper will transparently pass traffic, observing only pcq-rate. Some of the subscribers will receive full speed, and someone will get nothing at all.
Based on the above, if you have several channels, consider this functionality mandatory, even if the price is quite high.
And the price of this functional is the multiplication of the processor load from the shaper and the number of its rules by the number of channels served.
The second thing you need to pay attention to is the guaranteed speed of the channels.
If the speed on the channel floats within more than 20%, this is very bad. There are several ways out of this situation:
1. Use only guaranteed channels. This is almost a myth. Such channels provide mainly legal entities with all the consequences. Secondly, if the channel comes to the router by radio, there will be little sense from this.
2. Use not the entire channel capacity. Achieved by long-term tests and calculating its average speed. I think that you will not greatly appreciate the fixed use of only half the potential of the channel. But stability will increase significantly.
3. Using commercial (QOSEvxController) or self-written scripts to update the max-limit value on the channel. This solution is slightly better than the second option and allows you to receive from the channel a little more than its average speed.
The price of the issue is the Contract for legal entity or external scripts and some processor resources.
Third and last channels - Type of connection uplinks.
Yes, I mean the connection by radio, with all the consequences. With oncoming traffic, the performance of this channel decreases, and the speed considerably floats. The solution is the same as above, plus adding to the design of various priorities for the Download / Upload traffic. This functionality does not add significant CPU load.
The second thing we will notice is the number of tariff plans in the grid. Here you can say one thing - keep the middle ground. It is not necessary to prescribe only those tariffs that you have now, the grid of tariff plans must be thought out in advance, because it is much easier to raise them at the creation stage than to add them in the future by making mistakes and confusing in the thousands of mangle rules. But also do not get carried away, each extra tariff plan increases the load on the processor.
The third question to discuss is: “Should I give some type of traffic a higher priority?”
Of course, it is worth thinking about the implementation of this functionality in the design. Splitting the packet stream by at least two priorities will double the processor load, and using regular expressions at least one mangle rule will be dozens of times.
Therefore, this chip should only be used by owners of CCR, CHR, X86 series routers with a sufficient amount of free megahertz on the processor cores.
However, the usefulness of this function also has a very positive effect on the network.
First, a lot depends on who you provide the Internet to.
There are subscribers who have a computer strictly on "you" and this is the most painful group for technical support. They collect all the teasers on the Internet, respectively, on their computer just a zoo of viruses, Trojans and downloaders, and even the update center they themselves shake what they want and when they want. After school, their child returns, launches tanks, catches lags, and calls for technical support begin. You politely explain that they have computer problems and most often get an answer that they “fixed and adjusted everything two weeks ago” and that they have no problems. After all, father's funny pictures on the whole screen, which were asked to put money on some phone number, were deleted by Mom's familiar programmer from work.
And most often, such subscribers are difficult to reach and find the right words to convince. Alas, it is so!
When allocating a higher priority (a separate lane), for example, the same tank crew, similar problems are transferred from the category “sharp” to the category “sluggish”. And very often they decide on their own with time (the machine starts to blunt, Winlockers spoil the mood of the Pope, cryptographers finish the files), and it all hints that you have to invite a specialist to solve these problems.
, «» , , , . , , , - , . , , .. , , , ..
In the second case, when we are rescued by prioritization by type of traffic, these are some problems with our equipment or channels on the Internet. When the total band of our channels is significantly lacking, low priority traffic of equal subscribers is pressed in order to skip high priority traffic. Here the same bonus, gamers and especially tankers in the midst of game battles are very nervous people and while you are engaged in solving the problem it will be much easier for you to survive this malfunction if at this time you don’t break the phone so much as if all the services were dropped.
The fourth question for discussion will affect only those who have local traffic from subscribers exceeds the capacity of internal links to the network segment.
The most acute question is with those subproviders who distribute the Internet by radio on common equipment.
For example, take the Ubiquiti Rocket M5 base station with a good panel antenna, set by all the rules and working on a free frequency without interference.
The maximum number of subscribers (30 devices) is connected to this base, and for the purity of the theory, they are all at the same distance and with the same signals.
And here we have created greenhouse conditions for a beautiful box inside which the Chinese city ...
I ca n’t say that other manufacturers have everything super inside the case, but this manufacturer very carefully hides a very important parameter - the packet capacity of this device.
From my own experience I will say that for this device it lies in the range of 16000-20000. For Rocket M5 Titatium in the region of 20000-25000.
And what does this give us? When downloading torrents at a rate of 1 megabit per second (not the smallest packets, if that), about 800-1,100 packets per second are generated.
This tells us that in the worst of things, the maximum base performance is 15 megabits per second. And not 300 megabits as they say, many are sold and not 150 as they say more honest. And aggregation in the superframe there is an empty sound.
But this is the worst development, not all subscribers download only torrents, someone is surfing, someone is sitting on Skype, someone is watching a movie, etc.
The number of packages decreases, but the speed increases. So, the average throughput of this base station in real conditions is about 35-45 megabits. Its maximum is 70-80 megabits on large packets with TCP traffic.
Why do I actually lead: with 30 subscribers with tariffs of 5 megabits, this base will not cope in global prime time, which happens not so rarely. (The release of the expected films, sports events, etc.)
Even 20 * 5 is already a hundred megabits, of course, the base has its own queues, timeslots when using TDMA, etc., the base is supposed to distribute traffic fairly and equally. But in real conditions, when it is clearly overloaded by packets or radio, in the presence of interference, the difference of distances and signals, uniform division by TDMA is simply impossible.
If closer to the topic, we will call the base station a segment, because for normal providers, the networks are segmented and broadcasts over them without permission do not walk.
And for each segment we will make an additional separation and speed limit, so that in the event of a shortage of base resources, the speed would be divided evenly among those who need it.
Easy to say, but very expensive to do. After all, each segment (VLAN).
It will multiply the load from the shaper by the number of segments entered into the shaper.
This functionality is undoubtedly needed by wireless sub-providers, but it leads to a huge number of rules and a huge waste of system resources.
But all of them use it, it's just that this functionality is easily configured on the terminating router, from two routers it turns out a distributed system.
The first router monitors the speeds of channels on the Internet, prioritizing and cutting speeds. Next, the traffic passes to the second router, where the shaper monitors the load on the network segments. And also for inter-subscriber traffic, which I will tell you about.
The last question: “Why do we need
inter-subscriber traffic and how much will a rake hit the forehead?” Inter-subscriber traffic is needed primarily to reduce the load on the Internet channels.
A local retreker or other various services can be raised on the network, or without them at all.
The bottom line is that when downloading a torrent, the torrent client first of all turned to other subscribers and if they had the requested parts or files, they received them entirely within the network at maximum speed.
It is also possible to implement internal servers and services by the provider.
Well, here I already foresee: “But who needs your internal servers and retresers? Here every second optician ”
I have a client, an official provider. It has three channels of 4 megabits each from satellite modems and about 400 subscribers. In a radius of 700 km there are no optics, no cable, no fay, no zhoporez with 3-4g. In general, there is nothing. Ping 700ms. And here you are like cheese in oil, with optics and the 21st century. There will still be questions, why subproviders caching proxies, retresers and other gadgets?
So be inter-subscriber traffic!
No matter how good it may sound, this is the only thing that ROS of the sixth version cannot defeat. This is due to the fact that when replacing global-in, global-out and global-total that were in the fifth version, on global which is now in the sixth, there is no possibility to mark traffic twice and drive it through HTB twice.
The problem is that we are physically unable to tag traffic from one subscriber to another within the same router, since for one subscriber, the packet will be marked as outgoing, and for the second it is incoming. For mangle, this is a packet that matches the criteria for the two rules, first it will receive one label, and then it will be redistributed by another rule. And everything would work out if between the markings one could forcibly send a packet to the processing of queues. But miracles do not happen.
Someone will say or ask: "In the fifth version, everything will work out?" Yes, of course. Checked, works with a bang! Only here the fifth version has its drawbacks and is no longer suitable for the tasks that are required from this router.
How to be?There are some solutions to this problem, the traffic will be registered only in one direction and with a lower priority, the Internet traffic will have a higher priority. In addition, this stream is useful to limit. The scheme is quite complicated and is created for individual configurations. If one of the specialists has just read it and understood what I am talking about - contact me, maybe together we will come up with something more advanced.
Besides all this, inter-subscriber traffic cannot be marked on the same router with the control of the load on the Internet uplink. Even if you decide to risk the performance of the router and make an all-in-one combine (Monitoring the load on channels + cutting speed at rates + priorities + monitoring internal segments + marking inter-subscriber traffic), you will notice after a while that in the root queues of channels on the Internet a load is recorded that does not actually exist. This inter-subscriber traffic is marked, enters the queue, is transmitted to the root queue of the segment, and from there it enters the channel queue.
Changing the parent of the channel queue or segment will not give any positive result. In fact, it turns out that the channel is free, but the shaper will think that there is a load on it. The solution to this problem is a distributed system.
Well, that's how it would be decided what was happening, of course, if there is a billing, then it should support work with address lists for telling the micro-device what ip address and how much speed to issue. The same applies to the balancing script, it must report with its lists what ip address is, to which channel it is attached at a given time. In addition, if you create a distributed system on two routers, you will need to synchronize the address of the sheets between the routers, you can implement it by writing a script, or an external handler on api. Also, soon such a script will be available (EvxListSync).
I think that after we have decided on the necessary parameters, we should proceed from the words to the deed. In this example, I will describe the basic design, in which you can add some functionality to your liking or remove extra.
Suppose that we have two channels on the Internet and a balancer that scatters subscribers through channels and forms the ISP1 and ISP2 sheets that are dynamically needed address.
An individual shaper will be created for each channel.
In the example, four tariff plans will be considered, two for individuals and two for legal entities.
If there is a billing, it should add the ip addresses of users to the appropriate lists for linking the subscriber to the required tariff plan. If there is no billing, you will need to manually fill in these address sheets.
In addition to all this, we divide traffic by type into two priorities.
Mark all incoming traffic to the addresses from the “SHAPER_TARGET” list by assigning the “CLASS-B-DL” label to the packets . Next, we catch packets with the “CLASS-B-DL” label and reassign them by assigning a label of a higher priority class. In a higher priority will get: ICMP, DNS, SSH, TELNET, RDP and packets whose source address is any address from the CLASS-A-SITES list. We perform the same procedure for outgoing traffic: After these actions, we get four streams of tagged packets: CLASS-A-DL CLASS-B-DL CLASS-A-UL CLASS-B-UL We are looking for packets belonging to subscribers that are currently operating in these streams. on the first channel and remake them:
After redesigning, we will receive four additional streams:
ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL
Now we need to sort these four streams into tariff plans:
Address sheet “1024 -1024-8 "in the format" Incoming speed-Outgoing speed-Priority. " Priority is equal to 8 if a natural person and 7 if a legal entity. It is more convenient to manage billing sheets.
We select four streams for the tariff plan “1024-1024-8” two for loading, two for return: We repeat the actions for the three remaining tariff plans: After these actions, we received 16 streams of marked packages. Channel Streams: ISP1-CLASS-A-DL ISP1-CLASS-B-DL ISP1-CLASS-A-UL
ISP1-CLASS-B-UL
Lost relevance because All packages with these markings were re-sized.
But the common streams:
ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL
still contain packets of other channels, in our case: the ISP2 channel.
Next, you need to re-design for the second channel, similar to the first: We get another 16 streams for the second channel. In total, we have 32 streams, common class streams and channel streams have become irrelevant since all packages in them were re-sized and formed new 32 streams. At this marking is over.
, , /.
, .
Earlier, I mentioned problems that will arise when receiving Internet channels on the radio, it is also quite likely that the provider will give you a non-symmetrical channel, or you will use adsl or 3-4g.
Based on this, we immediately lay in the structure: the parent duplex queue and sub-queue for the simplex.
Parent queue for the first channel: Sub-lines for the simplex: After that, we can add finite descendants, priorities will be set in these queues. Tariff plan 1024-1024 for individuals on two priorities + priority of incoming traffic: The remaining three tariff plans: With the first channel finished, add the queues of the second channel by analogy with the first:
After that, you need to add to the address list “SHAPER_TARGET” subnet ranges with subscribers, make sure that the billing adds the addresses of subscribers to the desired lists, check whether the balancer adds the addresses of subscribers to the channel lists.
You also need to set max-limit values ​​in root queues, these values ​​should be 5-20% lower than the real speed that the provider gives you.
Total:
52 rules in Mangle, 8 profiles, 38 queues.
But if you approach more realistic conditions, you get huge numbers.
Take for example 5 channels and 12 tariff plans.
16 rules in Mangle to determine the types of traffic.
5 channels * 4 rules for sharing = 20 rules in Mangle
5 * (4 * 12 )=240 Mangle
mangle = 276 (260 )
12*2=24
Tree
5 channels for 3 root queues = 15 queues
5 channels * (4 queues for a tariff * 12 tariffs) = 240 queues
Total: 255 queues
And these figures are quite normal to get along with CCR, CHR, X86 if you do not mess with regular expressions. If you want to add another step to determine the type of traffic - multiply the number of queues and rules by two.
For those who, contrary to beliefs, want to fasten the control of internal network segments on the same router to this scheme - multiply the number of rules and queues by the number of segments and add the number of segments multiplied by two to the obtained value.
In this example, with ten segments, the number of rules in mangle will be about 2610, and the number of queues is about 2580.
In addition, if there is inter-subscriber traffic on the network, a rake, which I wrote earlier, will hit the forehead very painfully.
For these purposes, you need a second shaper on the second intermediate router, besides the fact that all this can be relatively simple to implement, the second router still has many useful advantages.
Moreover, the owners of hypervisors raise the second copy is worth nothing.
I think that now many will understand why on SOHO soap dishes with 680 megahertz on board you can only implement a simple seeder for two groups of users and no more.
Well, since I started talking about the second router and about the control of the segments, it’s not a sin to tell you how all this is done.
First of all, you need to mark the traffic on the second router.
Mark external incoming traffic by assigning a label: "EXT_CLASS-B_DL" Next, we catch packets with the label "EXT_CLASS-B_DL" and reassign them by assigning a label of a higher priority class. We do it by analogy as on the first router. After that we received two streams of labeled packets of external incoming traffic: EXT_CLASS-A_DL EXT_CLASS-B_DL Next we need to convert them into four streams, two streams for individuals and two for legal entities , we will do this by remarking according to the address of the tariff plans . Now we have four threads available: EXT_CLASS-A-FL_DL EXT_CLASS-B-FL_DL EXT_CLASS-A-UR_DL EXT_CLASS-B-UR_DL
:
:
EXT_CLASS-A-FL_DL
EXT_CLASS-B-FL_DL
EXT_CLASS-A-UR_DL
EXT_CLASS-B-UR_DL
EXT_CLASS-A-FL_UL
EXT_CLASS-B-FL_UL
EXT_CLASS-A-UR_UL
EXT_CLASS-B-UR_UL
, .. , .
Now we have reached the final stage of labeling. By using partitioned address sheets, we will be able to determine where and from where the packets go. In this example, we have only two segments VID30 and VID40.
Incoming traffic: Outgoing traffic, by analogy: Repeat the same for the second segment: Incoming traffic: Outgoing traffic: This marks the end.
There is nothing special, two default profiles
Root queue in which you can set max-limit (connection speed with the first router) Duplex sub-subnet to network segment: Simplex of the segment for download: Queues of descendants: Almost, the same for outgoing traffic: Simplex of the segment for returns: Queues of descendants: Repeat tree for the second segment (VID40) Segment Queue:
Loading:
Recoil:
That's all.
Naturally, the address list SHAPER_TARGET need to enter all the ranges of the segments, and in the lists of VID30 and VID40 segments of the segments that are on them.
Now I will tell how it works.
Shaper transparently passes all traffic through itself until a limit is reached, which of any of the parent queues. In simple words - while the segment capacity is enough, the shaper does not work, but if a segment has a lot of traffic and exceeds the limit - the speed is cut in accordance with the priorities.
As soon as the limit is reached, the priorities will be processed as follows:
Priority = 4
External traffic of high priority for legal entities is skipped.
Priority = 5
External traffic of low priority is skipped for legal entities. + External traffic of high priority for return for legal entities is skipped. +
External traffic of high priority is ignored for individuals.
Priority = 6
External traffic of low priority is ignored for downloading for individuals +
External traffic of high priority is passed on return for individuals +
External traffic of low priority is passed on for legal entities.
Priority = 7
Inter-subscriber traffic for download + is
skipped + External traffic of low priority for return for individuals is skipped.
Priority = 8
Inter-subscription traffic for return is skipped.
This behavior can be changed by changing the priority of the descendants in the tree, in this case, the priorities are set to "overlap", this allows you to "cram in nevi" in complex configurations, when eight priorities are not enough. In this example, this is only a demonstration of possibilities.
In addition to all priorities, each segment has a forty megabit duplex limit. This is related to the radio and discussed earlier. The exchange of inter-subscriber traffic of 20 megabits per reception and 20 megabits per return per segment is also forcibly limited.
With traffic inside this router, only incoming or outgoing inter-subscriber traffic will be registered.
As I wrote earlier, this rake arises from the fact that the same packet falls under the criteria of two rules, and this behavior cannot be defeated.
Some probably thought: “Inside the segment, the subnet is the same for everyone, they communicate with each other directly (via a base or a switch). How did the packages get into the router?
Internal traffic must be controlled or denied. Broadcast, viruses, scanners and other garbage are very detrimental to the network. If at the base or switch you enable isolation of subscribers, then they will not be able to see each other within this base or switch. But this, however, is not entirely correct and good. The best option is to terminate the individual VLANs on the switch or router. I use the analog ip unnumbered for the implementation of inter-subscriber traffic and control over it.
But this is a completely different topic.
I think it's worth it to finish on this, this wonderful opus.
By tradition, I post the ready-made RSC recent examples for importing into the system, as well as the address sheets for adding Wargaming, Warface and iccup servers to priority. In order to save you from copy-paste during the experiments.
RSC import file with control of channels, prioritization and tariffs (First router)
RSC import file with control of network segments, prioritization and control of inter-subscriber traffic (Second router)
RSC import file with address sheets for adding high priority servers Wargaming, Warface and iccup
PS I will I am glad to hear constructive criticism and comments on the data in the examples of designs. I will also be glad to communicate and exchange experience with experienced people in this field. My contacts you can find in the profile.
Thanks for attention!
- What is there to offer ... And then they write, they write ... the congress, the Germans are some ... The head swells. Take everything and share.
“So I thought,” exclaimed Philipp Philippovich, slapping his hand on the tablecloth, “and thought so.”
M. Bulgakov, "Heart of a Dog"
About the division of speed, prioritization, the work of the shaper and everything else is already a lot of things written and drawn. There are many articles, manuals, schemes and other things, including the materials I have written. But judging by the increasing flow of letters and messages, reviewing previous materials, I realized that some of the information is not as detailed as necessary, the other part is simply outdated and just confuses newcomers. In fact, the QOS on microtic is not as complicated as it seems, but it seems difficult because of the large number of interrelated nuances. In addition, it can be emphasized that it is extremely difficult to master this topic, guided only by theory, only by practice, and only by reading the theory and examples. The main crutch in this case is the lack of a visual representation in Mikrotik of what is happening inside the PCQ queue, and what cannot be seen and felt must be imagined. But the imagination of all is developed individually in one degree or another.Therefore, I decided to write another material in which I will mix theory with practice, visual examples and break this material into blocks from simple to complex. With each new example, I will add the necessary information, and at the very end you will get a complete picture of how it all works. I think that it will be much easier to understand the basic principles of building a shaper on microtic.
In this article, I will only consider Queue Tree queues using PCQ. Excuse me, Simple Queues for me is somewhat a wrong level of opportunity. Also, outdated material will not be described, which is applicable only to the fifth versions of ROS, although in some moments I will refer to it for comparison.
')
Let's start with a simple example.
We have a microtic:
WAN interface with white address (1.1.1.1) and an incoming speed of 32 megabits per second
LAN - with subnet 192.168.0.0/24
The task is to cut the incoming speed in various combinations (Download) for the subnet 192.168.0.0/24. We will not touch the outgoing speed (Upload) for the time being, but I note that its implementation is almost the same as the input speed.
In order to cut something in the microtic we must determine the criteria for selecting the traffic we need and select it. For this we need / ip firewall mangle.
Mangle can be represented as a kind of filter that can take packets and connections from a general stream according to certain criteria and perform certain actions with them.
Our only criterion is known: from the general flow, we only need packets that go to the 192.168.0.0/24 subnet. As an action with these packages, we will select the assignment of a label to the package, later on the basis of this labeling the packages can be processed in the Queue Tree.
In order to properly mark a package, you need to know which chains it passes in Mangle. To do this, you need to know the movement diagrams of the packets (Packet Flow) and not anyhow what, but fresh diagrams because in the sixth version of the ROS scheme has changed slightly. And naturally, having looked at these diagrams for the first time, you will have nothing but swear words on your lips.
Again, not everything is as difficult as it seems, these diagrams show how traffic flows in all cases, but we will need only a small part of them to work with the shaper.
Based on this diagram, you can understand that the traffic of interest to us is on the way:
Input Interface> PREROUTING -> FORWARD -> POSTROUTING -> Output Interface
The scheme with NAT enabled will be a little fatter:
Input Interface> PREROUTING> DST-NAT> FORWARD> POSTROUTING> SRC-NAT> Output Interface
Which chain to choose?
In the fifth version of ROS, besides where NAT is located, it was also necessary to know where the processing of the global-in, global-out and global-total queues are.
In the sixth version it became easier, because The above treatments were abolished and replaced with one global. And this global is at the very end of POSTROUTING, after it the queues of SimleQueue are processed and the packet is released at will. Based on this, it does not matter to us where he is now, since all marking treatments are made before it.
And if so, then the only restriction we create is only NAT, and the choice will depend on the direction of traffic that we want to mark. On this occasion, I added my own diagram:
As can be seen from the diagram, in order to label received packets, we need chains in which gray subnet 192.168.0.0/24 (dst-address) addresses are available.
And you can see them only in FORWARD and POSTROUTING.
In order to mark the Upload packets, chains are needed from the second half of the diagram, in which gray subnet 192.168.0.0/24 addresses are available (src-address).
And they are available in all three chains PREROUTING, FORWARD, POSTROUTING.
I am glad that I was not lazy and wrote so many extra books. And all in order to convey to you the information that, regardless of the direction we want to mark, you can choose the FORWARD chain in both cases. But this can not be done in the fifth version of ROS.
We decided on the chain, now we need to decide how we will tag the packages. First mark the connections, and only then mark the necessary packages in them? Or just mark the packages and everything will fly up?
Some time ago, during the time of the first versions of the sixth line, one good person wrote to me (for which I thank him so much!), And said that he had an interesting glitch in his system. He gave me a connection to TeamViewer and showed how the usual marking of packages marks a third (third! Karl!) Of packages more than marking with the same parameters but within the limits of connections. Accordingly, the speed in the tree was normal, but on the interfaces were a third higher. Tinkering for a long time, found nothing. I did the second marking according to the same criteria outside the connection, having previously disabled further transfers of already marked packets in the higher rules. All this is logged. Normal normal packages, why they did not fall into the connection did not understand.
I put the same version on my test bench (one WAN, one LAN and all this under double NAT) set up the rules and caught the same bug in my room. For four or five (no longer remember) versions, I caught this glitch. Then he stupidly did a load test and realized that the load on the stone was not so great as to use markings in the joints. Since then, on the labeling of packages in the connections - I scored. As hands reach - I will check, but for now I label the packages like this.
Well, that’s it. Rule in the studio!
By this rule, we mark all packets for which the dst-address is equal to the address to the “LAN” sheet, and we also assign them a “LAN” to the packet-mark.
/ip firewall mangle add action=mark-packet chain=forward comment=LAN disabled=no dst-address-list=LAN new-packet-mark=LAN passthrough=yes;
Also add the address list itself:
/ip firewall address-list add address=192.168.0.0/24 disabled=no list=LAN;
In this direction, marking in one direction is completed, in order to mark outgoing traffic, we need a copy of the rule, where dst-address-list = LAN is replaced by src-address-list = LAN
But as I wrote, for example, we take only incoming traffic.
We catch traffic in Queue Tree
In order to create a PCQ queue in this case, one rule and a profile in the Queue Type are required. But I will create two rules in order to show in one example how the queue behaves in either way or another when setting limits.
Parent turn
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8
There are a few points to clarify:
parent = global - In this parameter, you can specify either "global" or the name of the interface. The interface name here plays the role of a specific traffic direction filter and is used in complex configurations to exclude all directions except the specified interface and is valid only for this queue and its descendants. Always specify in this parameter “global” the effect will be the same, and there will be less problems.
max-limit = 30M - in the statement of the problem it is indicated that the channel gives us 32 meters, but you need to register a little less than the available speed. Otherwise, you will run into the shaper of your provider, yours just will not work.
burst-limit = 0 burst-threshold = 0 burst-time = 0s - disabled because their use does little for PCQ, but in the profile they are of sufficient relevance for use.
priority = 8 is the priority of the queue, 1 is the highest priority, 8 is the lowest priority. DOES NOT WORK if the queue has children.
Priorities work only among descendants, and they compete with each other not only within their parent, but also with the descendants of other parents, and only in the case of a common grandfather who limits the speed of these parasites. With the same priorities, they will distribute among themselves all the speed available to the grandfather. If they are different, they eat first priority ones from a common grandfather's bowl, then those who have a lower priority eat it, and then only if something remains, well, or the parents spread their grandfather to Limit-at. Although parents can arrange a battle of titans among their descendants, if they have not only Limit-at installed, but Max-limit as well. It will be in style: “do not devour everything, the grandfather has other children with grandchildren from their first marriage!”
Well yes postebalis and enough! I’ll tell you about the limits and priorities more clearly later.
In general, we created a parent, now he needs a descendant. But to add a child (the final queue), you must first add a profile. We add.
/queue type add kind=pcq name= PCQ_DOWNLOAD_LAN pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
kind = pcq - Indicates that the queue that uses this profile is the initiator of the PCQ subkeys
pcq-burst-rate = 0 pcq-burst-threshold = 0 pcq-burst-time = 10s - Burst Speed ​​Settings, more on that later.
pcq-classifier = dst-address - This parameter indicates by what classifier PCQ queues will be created. In this case, to the destination address (incoming traffic)
pcq-dst-address-mask = 32 and pcq-src-address-mask = 32 - set the number of addresses in one queue. (32 = one queue for one ip address)
pcq-rate = 0 - Sets the upper speed limit for one PCQ queue (in our case for one ip address) If zero is specified, the speed is unlimited and will be divided equally between queues (ip addresses). In our case, 30 megabits will be divided equally between the active queues (ip addresses).
pcq-limit = 50 - the limit of the size of one queue (for one ip address) All data in this queue is delayed when the limits are reached, all that does not fit into it is destroyed.
pcq-total-limit = 2000 - limit the size of all queues.
Now that we have a parent queue and a child profile, we will add the child itself:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=LAN packet-mark=LAN parent=DOWNLOAD priority=8 queue=PCQ_DOWNLOAD_LAN;
packet-mark = LAN - here we catch in a queue a stream of packets marked in the mangle.
parent = DOWNLOAD - indicated the parent who limited our speed.
queue = PCQ_DOWNLOAD_LAN - refer to the profile with settings in the Queue Type
Well, that's finished with the rules. Let's look at the visual chart.
Everything that happens at the top, you already know, further mixed labeled packets in a chaotic manner, are picked up by a queue by a child. And here the most interesting begins.
Suppose we now have three machines in the subnet: 192.168.0.1, 192.168.0.2 and 192.168.0.3.
Due to the fact that the descendant is tied to a profile with the name “PCQ_DOWNLOAD_LAN”, the profile was told to him: that it is necessary to create a separate PCQ queue for each address encountered in the marked dst-ip address.
We will have three PCQ queues (streams) inside the Queue Tree queue with the same pcq-rate, pcq-limit parameters and Burst speed settings.
In this case, the queue worked as a kind of packet sorter. And for each user created an individual queue.
Each queue goes through pcq-rate, it is this thing that holds packets in individual queues.
Next, the packets are mixed and arrive at the second part of the Queue Tree queue with the name “LAN”, where they are tested for the Max-Limit total speed, if it is exhausted, then this Max-limit will be divided equally between PCQ queues (streams) the delay is at the pcq-rate level, some queues are accelerated, some are slowed down. Anything that doesn't fit into pcq-limit is destroyed.
But we have not established this parameter in the “LAN” queue and therefore the traffic creeps up to the parent queue (DOWNLOAD). There everything happens by analogy, Max-Limit is checked and if it is reached - the parent queue kicks the pcq-rate to close the drawbar. Flow rates are aligned, and everything returns to normal.
Imagine for a second that we have not set Max-Limit in the parent queue. So, if no Max-Limit value was detected anywhere along the traffic path with pcq-rate = 0, then the whole queue will not work, all traffic will pass through the shaper without delay, since There is no one to tell pcq-rate that the channel is not rubber.
Many are tormented by the question if in this case pcq-rate = 0, there are three users, two are sleeping, and one is pumping. Does he live all 30 megabits? - Yes!
And what will happen if another one wakes up and starts pumping too? - Rebuild and alignment of speeds will be made. 30 megabits they share equally. The only caveat - it takes time, the second user will be a little slower to pick up speed than usual.
The essence of the mechanism is to delay and destroy packets that did not fit into the limit. The TCP protocol is designed in such a way that, within the framework of the connection, the server that sends data to the client, checks how it got to it, if the packets have increased latency or the packet is lost (sequence irregularity), the server lowers the sending speed to increase stability.
pcq-limit and pcq-total-limit are set experimentally, the greater the limit, the greater the delay and the more memory the router uses. The lower the limit, the more packages will be destroyed.
What happens if pcq-rate = 5M?
Each user will receive no more than 5 megabits. 3 active users * 5 megabits = 15 megabits.
Three active users, everyone downloads in full, pcq-rate = 11M?
The speed will rest on the Max-limit of the parent queue (30M) and this speed will be divided among users evenly by 10 megabits. If one of them leaves the download or slows down to at least 8 megabits, the other two will accelerate to 11 megabits.
I really hope that, according to this example, everything is clear, if it is not clear - read it again and again, then it will be more difficult.
Burst
Burst technology is designed to supply increased speed at a designated limit for a short time. It is advisable to use this feature at low-speed tariffs, to speed up web surfing or quickly upload data to applications. This function only works if pcq-rate is non-zero.
I will not load you to the blue in the form of graphs and formulas for calculation, I’ll better give an example.
Pcq-rate = 2M
pcq-burst-rate = 4M
pcq-burst-threshold = 1M
pcq-burst-time = 10s
The maximum user speed is 2 megabits. If the speed of its operation at the moment is less than 1 megabit (pcq-burst-threshold), the speed of 4 megabits (pcq-burst-rate) for 10 seconds (in practice less) will be available to pcq-burst-time. The counter starts ticking from the moment when the threshold of 1 megabit (pcq-burst-threshold) is exceeded, after a time the speed drops to pcq-rate so that Burst becomes available again - the user's speed should fall below 1 megabit and be there at least 10 seconds (pcq-burst-time)
It is clear that this is a very rough explanation, in fact, the time of availability of the burst is calculated by a complicated algorithm - the time is divided into 16 segments and taking into account almost all variable speeds and limits, the time of action is calculated.
This function consumes a significant amount of resources, use it wisely.
For reference: When making any changes, in any queue and in any of its manifestations (Tree or Simple) - all counters are reset, including and burst counters. If you use scripts to automatically correct Max-Limit values ​​of the QOSEvxController type - be prepared to abandon the Burst or use the queue check cycles in the QOSEvxController not so often.
Bucket with bolts (Bucket)
Just recently, in the sixth version of ROS for queues, a new parameter bucket-size (bucket size) has appeared. This parameter can be changed from 0.1 to 10 and is used to set the capacity of the bucket with tokens. Bucket capacity is calculated by the forum:
Capacity in megabytes = bucket-size * max-limit
A bucket with
What tokens are spent on.
/queue tree add name=download parent=global packet-mark=PC1-traffic max-limit=10M bucket-size=10;
In this example, the capacity of the bucket will be: (max-limit = 10M) * (bucket-size = 10) = 100 megabytes
If the user or users of the packet stream labeled “PC1-traffic” did not download anything at full speed until recently, the bucket with tokens in this queue will be full, and this will be as much as a hundred megabytes of traffic. And so they decided together, to swing something, and so, they will receive the first 100 megabytes of traffic without a speed limit on max-limit, when 100 megabytes will be downloaded and the queue will start to limit the speed according to the specified max-limit = 10M.
In addition, if the queue has a parent with a bold max-limit, then after the descendant has exhausted all of its tokens, it will begin to take tokens from the parent queue from its bucket.
What is it for?
Bucket-size is like a kind of burst, but not in terms of speed but in terms of traffic volume. Using it in conjunction with the PCQ queues will give only doubtful benefits. In single pfifo, red and sfq seed drills can be extremely useful. For PCQ queues, the only thing that comes to mind is that we limit the speed of the parent queues, which is slightly lower than the actual speed of the channel. Proper use of this function can more quickly exploit the full available channel speed and smooth out user activity peaks.
More detailed bucket job diagram:
Traffic marking equivalents
In this example, I indicated that we have one subnet (192.168.0.0/24) with three users (192.168.0.1, 192.168.0.2, 192.168.0.3). We marked traffic to these addresses with one rule in mangle and one address list.
Just in case, I will say that for mangle there is no difference, as we will feed him the addresses to be marked - they will be processed in the same way.
Subnet entirely:
/ip firewall address-list add address=192.168.0.0/24 disabled=no list=LAN;
Address Range:
/ip firewall address-list add address=192.168.0.1-192.168.0.3 disabled=no list=LAN;
Individual addresses:
/ip firewall address-list add address=192.168.0.1 disabled=no list=LAN;
/ip firewall address-list add address=192.168.0.2 disabled=no list=LAN;
/ip firewall address-list add address=192.168.0.3 disabled=no list=LAN;
The situation is similar with PCQ queues. A PCQ queue without problems parses one packet flow, marked by a single rule, consisting of addresses of different subnets on the sub-queue.
Suppose that we mixed three more users from another subnet (192.168.1.1, 192.168.1.2, 192.168.1.3). Just by adding the necessary entries to the address list. Then we get the following picture:
Based on all of the above, we can conclude that we operate not with subnets, but with groups of ip addresses that we create using address lists
In this case, it makes no sense to separately mark traffic, make two profiles and two queues.
This approach is necessary only in the following cases:
When you need to set an individual Max-Limit for the selected address group.
When a different priority is needed for address groups or traffic types.
When the implementation of various tariff plans for a group of addresses. (pcq-rate)
And in all possible combinations of the above cases.
Here is an example of how not to do it:
Full listing example:
/ip firewall mangle add action=mark-packet chain=forward comment=LAN disabled=no dst-address-list=LAN new-packet-mark=LAN passthrough=yes;
/ip firewall address-list add address=192.168.0.0/24 disabled=no list=LAN;
/queue type add kind=pcq name= PCQ_DOWNLOAD_LAN pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=LAN packet-mark=LAN parent=DOWNLOAD priority=8 queue=PCQ_DOWNLOAD_LAN;
An example of the second. The priority of some over others.
Suppose we are an organization administrator with a small number of employees.
We have the initial data:
WAN interface with white address (1.1.1.1) and an incoming speed of 32 megabits per second
LAN - with subnet 192.168.0.0/24 (Workstations of Directors)
LAN2 - with a subnet 192.168.1.0/24 (Workstations Managers)
In this example, we just have one channel and two groups of consumers with different priorities. Where directors take precedence over managers. In this case, for the implementation of this scheme will require separate labeling of packages and separate queues for user groups.
Marking Rules:
/ip firewall mangle add action=mark-packet chain=forward comment=GROUP-A_DW disabled=no dst-address-list= GROUP-A new-packet-mark= GROUP-A_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=GROUP-B_DW disabled=no dst-address-list= GROUP-B new-packet-mark= GROUP-B_DW passthrough=yes;
Two rules for marking traffic with different packet-mark and two lists for assigning group membership addresses.
/ip firewall address-list add address=192.168.0.0/24 disabled=no list=GROUP-A;
/ip firewall address-list add address=192.168.1.0/24 disabled=no list=GROUP-B;
It's time to create PCQ profiles for queues.
How many profiles are needed? In theory, one profile will be enough for downloading, but I always create a separate profile for each group and for each direction. This allows you to have flexible settings for the future, without additional intervention in the already created rules and queues
/queue type add kind=pcq name= GROUP-A_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= GROUP-B_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
Create a queue tree:
Parent queue:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8;
Descendants:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-A_DW packet-mark= GROUP-A_DW parent=DOWNLOAD priority=7 queue= GROUP-A_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name= GROUP-B_DW packet-mark= GROUP-B_DW parent=DOWNLOAD priority=8 queue= GROUP-B_DW;
In this example, there is nothing difficult, the difference between the queues only in different package markings and different priorities.
At low speeds, this scheme will transparently pass traffic through itself and any consumer can receive all 30M specified in the parent queue.
If there is a lack of speed in the parent queue, the speed will begin to be redistributed among consumers according to the following scheme:
The group with addresses GROUP-A_DW has a higher priority (priority = 7), it will be given the entire speed of the parent queue (30M) and is evenly divided between active consumers within this queue.
If this group has not utilized the entire available speed limit (30M), the remainder of this limit will be transferred to the queue with a lower GROUP-B_DW priority (priority = 8), where these residues will be evenly divided among active consumers within this queue.
If GROUP-A_DW has scrapped the entire available 30 megabit limit, GROUP-B_DW will not receive any speed at all and no opportunity to send and receive packets from the network.
In order for a group with a low priority to have at least a certain amount of speed, you can set the limit-at = 5M parameter in the queue. But this parameter can only be set together with the Max-Limit parameter, we do not need to limit the maximum speed of the group - so we just copy it from the parent queue.
And the second turn after the edits will look like this:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=5M max-limit=30M name=GROUP-B_DW packet-mark=GROUP-B_DW parent=DOWNLOAD priority=8 queue=GROUP-B_DW;
In such a case, if there is a shortage of speed in the parent queue, the low priority queue will always receive at least 5 megabits, which it can evenly divide between active consumers within this queue.
The third example. Implementation of tariff plans divided into groups with different priorities
In this example, a kind of hybrid will be considered, which includes implementations from the first two examples.
Suppose we are a subprovider with limited financial and technical capabilities. We have a narrow channel on the Internet, a couple of tariff plans and two categories of subscribers (individual and legal person). Most often, when providing services to legal entities, we get more benefits from them than from individuals at the same rates of speed. At the same time, we provide legal entities with some additional guarantees in the form of guaranteed speed and more operational technical support.
Well, as often happens - we got a little carried away and hooked up a little more subscribers than our channel can pull into the Internet. On the right - you need to expand the channel or connect an additional one with subsequent load balancing. But as already mentioned, this is not yet possible.
But there is not enough speed at prime time, legal entities are starting to call and complain about speed, packet delays, telephony stuttering, etc., which are inconsistent with the tariff plan.
The shaper with priorities as in the second example will help to partially alleviate this situation, the only differences are that in this example the speed per subscriber is strictly limited and there are several tariff plans.
As in the previous examples, we consider only the incoming speed. However, to avoid confusion in comments, label names and queue names, upload speed will be present.
Abbreviations:
FIZ - an individual.
UR - a legal entity.
1024K-1024K - Speed ​​by rate: Download-Upload
DW- Download
UL - Upload
Package marking:
/ip firewall mangle add action=mark-packet chain=forward comment=FIZ_1024K-1024K_DW disabled=no dst-address-list= FIZ_1024K-1024K new-packet-mark= FIZ_1024K-1024K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=FIZ_3072K-3072K_DW disabled=no dst-address-list= FIZ_3072K-3072K new-packet-mark= FIZ_3072K-3072K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=UR_1024K-1024K_DW disabled=no dst-address-list= UR_1024K-1024K new-packet-mark= UR_1024K-1024K_DW passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=UR_3072K-3072K_DW disabled=no dst-address-list= UR_3072K-3072K new-packet-mark= UR_3072K-3072K_DW passthrough=yes;
Four marking rules that will give us four streams of tagged packages sorted according to four tariff plans (Two for individuals and two for legal entities)
To bind a subscriber to a specific tariff plan, you need to put his ip address in the desired address list:
/ip firewall address-list add address=192.168.0.1 disabled=no list= FIZ_1024K-1024K;
/ip firewall address-list add address=192.168.0.2 disabled=no list= FIZ_3072K-3072K;
/ip firewall address-list add address=192.168.0.3 disabled=no list= FIZ_3072K-3072K;
/ip firewall address-list add address=192.168.0.4 disabled=no list= UR_3072K-3072K;
/ip firewall address-list add address=192.168.0.5 disabled=no list= UR_3072K-3072K;
Etc.
Now you need to add the necessary profiles for the queues:
/queue type add kind=pcq name= FIZ_1024K-1024K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= FIZ_3072K-3072K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=3M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= UR_1024K-1024K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=1M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
/queue type add kind=pcq name= UR_3072K-3072K_DW pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=3M pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000;
Again, I created four profiles instead of two, to preserve the flexibility of settings for the future.
Next, build the queue tree:
Parent queue:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=30M name=DOWNLOAD parent=global priority=8
Descendants:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=FIZ_1024K-1024K_DW packet-mark=FIZ_1024K-1024K_DW parent=DOWNLOAD priority=8 queue= FIZ_1024K-1024K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=FIZ_3072K-3072K_DW packet-mark=FIZ_3072K-3072K_DW parent=DOWNLOAD priority=8 queue= FIZ_3072K-3072K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=UR_1024K-1024K_DW packet-mark=UR_1024K-1024K_DW parent=DOWNLOAD priority=7 queue= UR_1024K-1024K_DW;
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=UR_3072K-3072K_DW packet-mark=UR_3072K-3072K_DW parent=DOWNLOAD priority=7 queue= UR_3072K-3072K_DW;
When implementing this example, everything will work as follows:
At low speeds, subscribers without problems get their tariff rate, which is limited by the pcq-rate parameter.But the most interesting thing begins when there are more active subscribers than a channel can produce.
The parent queue is limited to 30 megabits.
Tariff plans of individuals and individuals themselves are equal.
Tariff plans of legal entities and legal entities themselves are equal among themselves.
But due to the fact that the queue of legal entities has a higher priority, it follows that the legal entities themselves with their tariff plans also have a higher priority - and they will be processed first.
All available speed is given in tariffs for legal entities, each such subscriber is limited by the rate of the tariff specified in the pcq-rate parameter. However, if these subscribers work intensively and their traffic consumption exceeds 30 megabits in total, we get the following picture:
30 megabits will be divided equally between legal entities, based on the current number of packets in each PCQ queue. In fact, it is not so easy to explain this situation, but I will try.
Suppose that all of the listed legal entities in our country swing “to the fullest”. At the moment there are four subscribers with a tariff of 1 megabit and twelve subscribers with a tariff of 3 megabits.
4 * 1M = 4 megabit
12 * 3M = 36 megabit
4M + 36M = 40 megabit is required for subscribers with the same priority.
But we have only 30 megabits. Everything would be just in the case of the same tariff plans: 30 megabits would be equally divided between subscribers and that's it. But how will the speed be distributed if our tariffs are different within the same priority group?
How will the lack of speed be distributed?
Two scenarios come to mind, but only one of them is correct.
The lack of speed will be distributed as a percentage based on the speed of the tariff plan. Something like this:
(100% / 40 megabits which are required) = 2.5
30 30 megabits which are * 2.5 = 75% of what we need.
(1 megabit / 100%) * 75% = 0.75 megabits
(3 megabits / 100%) * 75% = 2.25 megabits
Check:
4 subscribers with a tariff of 1M (4 * 0.75) = 3 megabits.
12 subscribers with a tariff of 3M (12 * 2.25) = 27 megabits.
27 + 3 = 30 megabits.
In principle, it is logical and relatively honest, but unfortunately this scenario will be handled a little differently, namely:
All available speed (30 megabits) will be distributed evenly between the participants in equal units of time.
Imagine a vat with 30 liters of water, from which pipes of the same cross section and N are the number of glasses of different sizes on the table, into which a limited volume of water is simultaneously poured in equal streams. In our example, the smallest glass has a volume of one liter, a bigger glass - three liters. (Three liters! Karl!) As soon as the small glasses are filled, they stop pouring water. All remaining water will continue to be poured into larger glasses. If after this the water in the vat remains, it will be poured into glasses on another low-priority table. But water, we do not even have enough for one table.
Complicated calculations:
First stage, first time interval:
4 cups per liter = 4 liters
12 glasses of three liters, but this time interval is filled with only liter = 12 liters.
30 liters - (4 + 12) = 14 liters of water left in the tank.
The second stage, the second time interval:
Due to the fact that there are no glasses of more than three liters in the example, we simply divide the remaining water between the three-liter glasses.
14 liters / 12 glasses = 1,1666666666666666666666666666667
Total calculations: The
user will receive the entire megabit at a rate of 1 megabit.
A user at a rate of 3 megabits will receive 1+ 1.16 = 2.16 megabits.
Same thing if you use simple calculations:
(30 liters - 1 liter * 4) / 12 = 2.16
If you look closely at both examples (incorrect and correct), you can see that in the first example, the total lack of speed on the tariff for all is exactly a quarter of the declared speed and all tariffs suffered the same way. In the second case, small tariff plans did not feel the shortage and received the declared speed, however, the tariffs with a higher speed felt a shortage of almost a third.
Based on the unduly outlined and not the most successful metaphor, we can conditionally say that tariffs with low speeds have a certain priority over tariffs with higher speeds, with a lack of speed, even with the same priority.
Yes, this is not entirely fair, but, unfortunately, this behavior of the shaper cannot be changed.
Here at this moment the point of view of Mr. Sharikov abruptly went out.
Not everyone will suffer evenly, but only those who have a more cheerful tariff plan. Well, as usual, the more speed - the more the subscriber pays. If this situation is even more or less permissible with individuals, then with legal entities it cannot even be called an annoying misunderstanding.
Well, let's return to the further discussion ...
Under these conditions, it can be seen that a channel of 30 megabits is not enough even to service the tariff plans of legal entities. Therefore, while legal entities intensively receive data, individuals do not receive any speed at all. This problem can be solved by setting the limit-at parameter, but in this case it will further reduce the available speed for legal entities.
It is clear that such a situation in reality will be equal to disaster. But we will push the disaster away and imagine that there are not so many legal entities. Namely: 2 with tariffs of 1 megabit and two with tariffs of 3 megabits. And they swing "to the fullest."
By simple calculations (2 * 1 + 2 * 3 = 8, 30-8 = 22), we understand that after servicing legal entities, the queue of individuals will reach only 22 megabits and they will be divided between them according to their tariffs. If there are too many individuals and this speed is not enough for them, the division will start as in the above described case with a large number of legal entities.
But no matter how fast individuals have enough speed, legal entities will be served first.
Fourth example. Priority of one type of traffic over another
In addition to the classical system of priorities, when the flow is divided into several groups of subscribers with different priorities, you can tie additional criteria for the division of priorities.
On this subject, you can argue for hours. Some people will say that under special circumstances, it is certainly worth using priorities. And, of course, they will provide weighty arguments in favor of these decisions. Others will start shouting about performance and how ethical this solution is - they say who we are to decide for the user or subscriber what type of traffic is more important to him.
I never got into this stupid holivar. Just in view of the great experience I have my own point of view on this matter. It all depends on each specific case and type of application of this technology.
, — , , , (. — icmp). , , .
There are also a lot of examples where these solutions have found their place and have significantly improved the work of the network and the reputation of these sub-providers. In some cases, it seemed that the use of prioritization in a particular case was unjustified (wide channels, everything is enough for everything and this feature simply loads the processor), however, with four outlines from the heap out of six, the speed was sorely lacking. And this supposedly unnecessary feature has greatly reduced the number of calls to technical support. Yes, the speed of downloading torrents significantly slipped; nevertheless, there were no complaints from “tankers” about the long ping and lags in the game.
In addition to all this, those people who have more experience know that the word prioritization means a very broad topic and various uses. I think it is worthwhile to list the main types:
The user thread is divided into two, with different priorities. The separation criteria can be ports, protocols, destination addresses, source addresses, and entire subnets.
Performance for high priority is achieved by allocating additional speed bandwidth in excess of the subscriber rate and a higher priority queue. Thus, the subscriber receives the rate of the tariff under the high priority + the rate of the tariff for the rest of the traffic. In fact: the subscriber receives the tariff rate multiplied by two. In practice, with free uplink and full use by the subscriber of their speed at the rate, the subscriber, on average, uses the rate of the tariff + 20%. If there is a shortage of uplink, low-priority traffic is delayed (the band is narrowed), high-priority traffic is passed (a separate band with a higher priority).
Prioritization in the direction of external <-> internal
The user thread is divided into two, with different priorities. The separation criteria are usually subnets. In one stream, external traffic goes to the world, in the second, internal or inter-subscriber traffic. It is used extremely rarely, usually in distributed systems consisting of several routers.
Prioritization in the direction of external traffic Download <-> Upload
Almost not used in wired networks. Wireless network administrators know that with one-way data transmission via radio equipment (simplex), the speed is several times higher than in the presence of counter traffic (duplex). Most often, if there is oncoming traffic, more than 30% of the link is highly degraded.
For example:
UDP test on UBNT bridges via AirOS
simplex ~ 130-160 megabit / s.
Duplex ~ 40-50 megabits / c.
In the sixth version of ROS with its changes (the global root queue and forward mark), it became possible to control duplex traffic with restriction and decrease in the priority of outgoing traffic from subscribers.
This theory mainly relates to B / G / N, when using equipment operating in AC mode, the counter traffic is not so bad.
Harsh practice
Well, well, the theory and the basics are clear. There is a real task to make some smart shaper. Where to begin?What factors should be considered in order not to collect all the rakes and subsequently not to redo everything all over again?
Before you create some design, the shaper must first be determined with a variety of parameters that your network has, or will have in the future. If you do not do this now, then in the future there may be problems that will force you to rework the structure from scratch. It is also worth remembering that each new function, requirement or criterion will cost processor time. Most often, this cost will increase exponentially. Therefore, think twice about how critical and appropriate this function is in your configuration.
The first thing we start with is the channels on the Internet.
The first thing you need to pay attention to is the number of channels. If you have several channels on the Internet or only plan to use several channels in the future, then most likely you will need to make a unique shaper for each channel.
I'll explain why.
When creating a common shaper, you will need to set the max-limit value in the root queue, which will be equal to the sum of the speeds of your channels. In theory, this will work, but in practice, not everything is as fabulous as it seems.
First, no matter how cool the load balancer between the channels is between the channels - there will always be a certain imbalance. Different load on the channels of at least 1% will disrupt the stable operation of the shaper and at least 1 subscriber on each channel will receive less of the tariff rate.
Secondly, the speed of some channels may “float” from time to time and as part of the balancing this will lead to a crash. Neither the balancer nor the shaper will know about the real uplink speeds. And even an artificially created supply of capacity in this case will not save.
Third, if one of the channels drops, the total capacity will change, and the max-limit value in the queue will become irrelevant. As a result, the shaper will transparently pass traffic, observing only pcq-rate. Some of the subscribers will receive full speed, and someone will get nothing at all.
Based on the above, if you have several channels, consider this functionality mandatory, even if the price is quite high.
And the price of this functional is the multiplication of the processor load from the shaper and the number of its rules by the number of channels served.
The second thing you need to pay attention to is the guaranteed speed of the channels.
If the speed on the channel floats within more than 20%, this is very bad. There are several ways out of this situation:
1. Use only guaranteed channels. This is almost a myth. Such channels provide mainly legal entities with all the consequences. Secondly, if the channel comes to the router by radio, there will be little sense from this.
2. Use not the entire channel capacity. Achieved by long-term tests and calculating its average speed. I think that you will not greatly appreciate the fixed use of only half the potential of the channel. But stability will increase significantly.
3. Using commercial (QOSEvxController) or self-written scripts to update the max-limit value on the channel. This solution is slightly better than the second option and allows you to receive from the channel a little more than its average speed.
The price of the issue is the Contract for legal entity or external scripts and some processor resources.
Third and last channels - Type of connection uplinks.
Yes, I mean the connection by radio, with all the consequences. With oncoming traffic, the performance of this channel decreases, and the speed considerably floats. The solution is the same as above, plus adding to the design of various priorities for the Download / Upload traffic. This functionality does not add significant CPU load.
The second thing we will notice is the number of tariff plans in the grid. Here you can say one thing - keep the middle ground. It is not necessary to prescribe only those tariffs that you have now, the grid of tariff plans must be thought out in advance, because it is much easier to raise them at the creation stage than to add them in the future by making mistakes and confusing in the thousands of mangle rules. But also do not get carried away, each extra tariff plan increases the load on the processor.
The third question to discuss is: “Should I give some type of traffic a higher priority?”
Of course, it is worth thinking about the implementation of this functionality in the design. Splitting the packet stream by at least two priorities will double the processor load, and using regular expressions at least one mangle rule will be dozens of times.
Therefore, this chip should only be used by owners of CCR, CHR, X86 series routers with a sufficient amount of free megahertz on the processor cores.
However, the usefulness of this function also has a very positive effect on the network.
First, a lot depends on who you provide the Internet to.
There are subscribers who have a computer strictly on "you" and this is the most painful group for technical support. They collect all the teasers on the Internet, respectively, on their computer just a zoo of viruses, Trojans and downloaders, and even the update center they themselves shake what they want and when they want. After school, their child returns, launches tanks, catches lags, and calls for technical support begin. You politely explain that they have computer problems and most often get an answer that they “fixed and adjusted everything two weeks ago” and that they have no problems. After all, father's funny pictures on the whole screen, which were asked to put money on some phone number, were deleted by Mom's familiar programmer from work.
And most often, such subscribers are difficult to reach and find the right words to convince. Alas, it is so!
When allocating a higher priority (a separate lane), for example, the same tank crew, similar problems are transferred from the category “sharp” to the category “sluggish”. And very often they decide on their own with time (the machine starts to blunt, Winlockers spoil the mood of the Pope, cryptographers finish the files), and it all hints that you have to invite a specialist to solve these problems.
, «» , , , . , , , - , . , , .. , , , ..
In the second case, when we are rescued by prioritization by type of traffic, these are some problems with our equipment or channels on the Internet. When the total band of our channels is significantly lacking, low priority traffic of equal subscribers is pressed in order to skip high priority traffic. Here the same bonus, gamers and especially tankers in the midst of game battles are very nervous people and while you are engaged in solving the problem it will be much easier for you to survive this malfunction if at this time you don’t break the phone so much as if all the services were dropped.
The fourth question for discussion will affect only those who have local traffic from subscribers exceeds the capacity of internal links to the network segment.
The most acute question is with those subproviders who distribute the Internet by radio on common equipment.
For example, take the Ubiquiti Rocket M5 base station with a good panel antenna, set by all the rules and working on a free frequency without interference.
The maximum number of subscribers (30 devices) is connected to this base, and for the purity of the theory, they are all at the same distance and with the same signals.
And here we have created greenhouse conditions for a beautiful box inside which the Chinese city ...
I ca n’t say that other manufacturers have everything super inside the case, but this manufacturer very carefully hides a very important parameter - the packet capacity of this device.
From my own experience I will say that for this device it lies in the range of 16000-20000. For Rocket M5 Titatium in the region of 20000-25000.
And what does this give us? When downloading torrents at a rate of 1 megabit per second (not the smallest packets, if that), about 800-1,100 packets per second are generated.
This tells us that in the worst of things, the maximum base performance is 15 megabits per second. And not 300 megabits as they say, many are sold and not 150 as they say more honest. And aggregation in the superframe there is an empty sound.
But this is the worst development, not all subscribers download only torrents, someone is surfing, someone is sitting on Skype, someone is watching a movie, etc.
The number of packages decreases, but the speed increases. So, the average throughput of this base station in real conditions is about 35-45 megabits. Its maximum is 70-80 megabits on large packets with TCP traffic.
Why do I actually lead: with 30 subscribers with tariffs of 5 megabits, this base will not cope in global prime time, which happens not so rarely. (The release of the expected films, sports events, etc.)
Even 20 * 5 is already a hundred megabits, of course, the base has its own queues, timeslots when using TDMA, etc., the base is supposed to distribute traffic fairly and equally. But in real conditions, when it is clearly overloaded by packets or radio, in the presence of interference, the difference of distances and signals, uniform division by TDMA is simply impossible.
If closer to the topic, we will call the base station a segment, because for normal providers, the networks are segmented and broadcasts over them without permission do not walk.
And for each segment we will make an additional separation and speed limit, so that in the event of a shortage of base resources, the speed would be divided evenly among those who need it.
Easy to say, but very expensive to do. After all, each segment (VLAN).
It will multiply the load from the shaper by the number of segments entered into the shaper.
This functionality is undoubtedly needed by wireless sub-providers, but it leads to a huge number of rules and a huge waste of system resources.
But all of them use it, it's just that this functionality is easily configured on the terminating router, from two routers it turns out a distributed system.
The first router monitors the speeds of channels on the Internet, prioritizing and cutting speeds. Next, the traffic passes to the second router, where the shaper monitors the load on the network segments. And also for inter-subscriber traffic, which I will tell you about.
The last question: “Why do we need
inter-subscriber traffic and how much will a rake hit the forehead?” Inter-subscriber traffic is needed primarily to reduce the load on the Internet channels.
A local retreker or other various services can be raised on the network, or without them at all.
The bottom line is that when downloading a torrent, the torrent client first of all turned to other subscribers and if they had the requested parts or files, they received them entirely within the network at maximum speed.
It is also possible to implement internal servers and services by the provider.
Well, here I already foresee: “But who needs your internal servers and retresers? Here every second optician ”
I have a client, an official provider. It has three channels of 4 megabits each from satellite modems and about 400 subscribers. In a radius of 700 km there are no optics, no cable, no fay, no zhoporez with 3-4g. In general, there is nothing. Ping 700ms. And here you are like cheese in oil, with optics and the 21st century. There will still be questions, why subproviders caching proxies, retresers and other gadgets?
So be inter-subscriber traffic!
No matter how good it may sound, this is the only thing that ROS of the sixth version cannot defeat. This is due to the fact that when replacing global-in, global-out and global-total that were in the fifth version, on global which is now in the sixth, there is no possibility to mark traffic twice and drive it through HTB twice.
The problem is that we are physically unable to tag traffic from one subscriber to another within the same router, since for one subscriber, the packet will be marked as outgoing, and for the second it is incoming. For mangle, this is a packet that matches the criteria for the two rules, first it will receive one label, and then it will be redistributed by another rule. And everything would work out if between the markings one could forcibly send a packet to the processing of queues. But miracles do not happen.
Someone will say or ask: "In the fifth version, everything will work out?" Yes, of course. Checked, works with a bang! Only here the fifth version has its drawbacks and is no longer suitable for the tasks that are required from this router.
How to be?There are some solutions to this problem, the traffic will be registered only in one direction and with a lower priority, the Internet traffic will have a higher priority. In addition, this stream is useful to limit. The scheme is quite complicated and is created for individual configurations. If one of the specialists has just read it and understood what I am talking about - contact me, maybe together we will come up with something more advanced.
Besides all this, inter-subscriber traffic cannot be marked on the same router with the control of the load on the Internet uplink. Even if you decide to risk the performance of the router and make an all-in-one combine (Monitoring the load on channels + cutting speed at rates + priorities + monitoring internal segments + marking inter-subscriber traffic), you will notice after a while that in the root queues of channels on the Internet a load is recorded that does not actually exist. This inter-subscriber traffic is marked, enters the queue, is transmitted to the root queue of the segment, and from there it enters the channel queue.
Changing the parent of the channel queue or segment will not give any positive result. In fact, it turns out that the channel is free, but the shaper will think that there is a load on it. The solution to this problem is a distributed system.
Well, that's how it would be decided what was happening, of course, if there is a billing, then it should support work with address lists for telling the micro-device what ip address and how much speed to issue. The same applies to the balancing script, it must report with its lists what ip address is, to which channel it is attached at a given time. In addition, if you create a distributed system on two routers, you will need to synchronize the address of the sheets between the routers, you can implement it by writing a script, or an external handler on api. Also, soon such a script will be available (EvxListSync).
Practical and final part:
I think that after we have decided on the necessary parameters, we should proceed from the words to the deed. In this example, I will describe the basic design, in which you can add some functionality to your liking or remove extra.
Suppose that we have two channels on the Internet and a balancer that scatters subscribers through channels and forms the ISP1 and ISP2 sheets that are dynamically needed address.
An individual shaper will be created for each channel.
In the example, four tariff plans will be considered, two for individuals and two for legal entities.
If there is a billing, it should add the ip addresses of users to the appropriate lists for linking the subscriber to the required tariff plan. If there is no billing, you will need to manually fill in these address sheets.
In addition to all this, we divide traffic by type into two priorities.
Markup
Mark all incoming traffic to the addresses from the “SHAPER_TARGET” list by assigning the “CLASS-B-DL” label to the packets . Next, we catch packets with the “CLASS-B-DL” label and reassign them by assigning a label of a higher priority class. In a higher priority will get: ICMP, DNS, SSH, TELNET, RDP and packets whose source address is any address from the CLASS-A-SITES list. We perform the same procedure for outgoing traffic: After these actions, we get four streams of tagged packets: CLASS-A-DL CLASS-B-DL CLASS-A-UL CLASS-B-UL We are looking for packets belonging to subscribers that are currently operating in these streams. on the first channel and remake them:
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-B-DL dst-address-list=SHAPER_TARGET new-packet-mark=CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-ICMP-DL new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=icmp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-DNS_TCP-DL dst-port=53 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-DNS_UDP-DL dst-port=53 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=udp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-SSH-DL dst-port=22 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-TELNET-DL dst-port=23 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-RDP-DL dst-port=3389 new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=CLASS-A-SITES-DL new-packet-mark=CLASS-A-DL packet-mark=CLASS-B-DL src-address-list=CLASS-A-SITES;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-B-UL new-packet-mark=CLASS-B-UL src-address-list=SHAPER_TARGET;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-ICMP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=icmp;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-DNS_TCP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=53;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-DNS_UDP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=udp src-port=53;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-SSH-UP new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=22;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-TELNET-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=23;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-RDP-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL protocol=tcp src-port=3389;
/ip firewall mangle add action=mark-packet chain= forward comment=CLASS-A-SITES-UL new-packet-mark=CLASS-A-UL packet-mark=CLASS-B-UL src-address-list=CLASS-A-SITES;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-A-DL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-A-DL packet-mark=CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-B-DL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-B-DL packet-mark=CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-A-UL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-A-UL packet-mark=CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1-CLASS-B-UL dst-address-list=ISP1 new-packet-mark=ISP1-CLASS-B-UL packet-mark=CLASS-B-UL;
After redesigning, we will receive four additional streams:
ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL
Now we need to sort these four streams into tariff plans:
Address sheet “1024 -1024-8 "in the format" Incoming speed-Outgoing speed-Priority. " Priority is equal to 8 if a natural person and 7 if a legal entity. It is more convenient to manage billing sheets.
We select four streams for the tariff plan “1024-1024-8” two for loading, two for return: We repeat the actions for the three remaining tariff plans: After these actions, we received 16 streams of marked packages. Channel Streams: ISP1-CLASS-A-DL ISP1-CLASS-B-DL ISP1-CLASS-A-UL
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-A_DL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-B_DL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-A_UL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-8_CLASS-B_UL dst-address-list=1024-1024-8 new-packet-mark=ISP1_1024-1024-8_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-A_DL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-B_DL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-A_UL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-8_CLASS-B_UL dst-address-list=2048-2048-8 new-packet-mark=ISP1_2048-2048-8_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-A_DL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-B_DL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-A_UL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_1024-1024-7_CLASS-B_UL dst-address-list=1024-1024-7 new-packet-mark=ISP1_1024-1024-7_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-A_DL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-A_DL packet-mark=ISP1-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-B_DL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-B_DL packet-mark=ISP1-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-A_UL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-A_UL packet-mark=ISP1-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP1_2048-2048-7_CLASS-B_UL dst-address-list=2048-2048-7 new-packet-mark=ISP1_2048-2048-7_CLASS-B_UL packet-mark=ISP1-CLASS-B-UL;
ISP1-CLASS-B-UL
Lost relevance because All packages with these markings were re-sized.
But the common streams:
ISP1-CLASS-A-DL
ISP1-CLASS-B-DL
ISP1-CLASS-A-UL
ISP1-CLASS-B-UL
still contain packets of other channels, in our case: the ISP2 channel.
Next, you need to re-design for the second channel, similar to the first: We get another 16 streams for the second channel. In total, we have 32 streams, common class streams and channel streams have become irrelevant since all packages in them were re-sized and formed new 32 streams. At this marking is over.
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-A-DL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-A-DL packet-mark=CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-B-DL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-B-DL packet-mark=CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-A-UL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-A-UL packet-mark=CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2-CLASS-B-UL dst-address-list=ISP2 new-packet-mark=ISP2-CLASS-B-UL packet-mark=CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-A_DL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-B_DL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-A_UL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-8_CLASS-B_UL dst-address-list=1024-1024-8 new-packet-mark=ISP2_1024-1024-8_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-A_DL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-B_DL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-A_UL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-8_CLASS-B_UL dst-address-list=2048-2048-8 new-packet-mark=ISP2_2048-2048-8_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-A_DL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-B_DL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-A_UL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_1024-1024-7_CLASS-B_UL dst-address-list=1024-1024-7 new-packet-mark=ISP2_1024-1024-7_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-A_DL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-A_DL packet-mark=ISP2-CLASS-A-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-B_DL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-B_DL packet-mark=ISP2-CLASS-B-DL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-A_UL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-A_UL packet-mark=ISP2-CLASS-A-UL;
/ip firewall mangle add action=mark-packet chain=forward comment=ISP2_2048-2048-7_CLASS-B_UL dst-address-list=2048-2048-7 new-packet-mark=ISP2_2048-2048-7_CLASS-B_UL packet-mark=ISP2-CLASS-B-UL;
Profiles
, , /.
/queue type add kind=pcq name=DL-1024-1024-8 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;
/queue type add kind=pcq name=UL-1024-1024-8 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;
/queue type add kind=pcq name=DL-2048-2048-8 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;
/queue type add kind=pcq name=UL-2048-2048-8 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;
/queue type add kind=pcq name=DL-1024-1024-7 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;
/queue type add kind=pcq name=UL-1024-1024-7 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=1M pcq-src-address6-mask=64 pcq-burst-rate=2M pcq-burst-threshold=1200K pcq-burst-time=15s;
/queue type add kind=pcq name=DL-2048-2048-7 pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;
/queue type add kind=pcq name=UL-2048-2048-7 pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=2M pcq-src-address6-mask=64 pcq-burst-rate=4M pcq-burst-threshold=2500K pcq-burst-time=15s;
, .
Tree
Earlier, I mentioned problems that will arise when receiving Internet channels on the radio, it is also quite likely that the provider will give you a non-symmetrical channel, or you will use adsl or 3-4g.
Based on this, we immediately lay in the structure: the parent duplex queue and sub-queue for the simplex.
Parent queue for the first channel: Sub-lines for the simplex: After that, we can add finite descendants, priorities will be set in these queues. Tariff plan 1024-1024 for individuals on two priorities + priority of incoming traffic: The remaining three tariff plans: With the first channel finished, add the queues of the second channel by analogy with the first:
/queue tree add name=ISP1-Duplex parent=global queue=default;
/queue tree add name=DL-ISP1 parent=ISP1-Duplex queue=default;
/queue tree add name=UL-ISP1 parent=ISP1-Duplex queue=default;
/queue tree add name=DL-ISP1_1024-1024-8_CLASS-A packet-mark=ISP1_1024-1024-8_CLASS-A_DL parent=DL-ISP1 priority=5 queue=DL-1024-1024-8;
/queue tree add name=DL-ISP1_1024-1024-8_CLASS-B packet-mark=ISP1_1024-1024-8_CLASS-B_DL parent=DL-ISP1 priority=6 queue=DL-1024-1024-8;
/queue tree add name=UL-ISP1_1024-1024-8_CLASS-A packet-mark=ISP1_1024-1024-8_CLASS-A_UL parent=UL-ISP1 priority=7 queue=UL-1024-1024-8;
/queue tree add name=UL-ISP1_1024-1024-8_CLASS-B packet-mark=ISP1_1024-1024-8_CLASS-B_UL parent=UL-ISP1 priority=8 queue=UL-1024-1024-8;
/queue tree add name=DL-ISP1_2048-2048-8_CLASS-A packet-mark=ISP1_2048-2048-8_CLASS-A_DL parent=DL-ISP1 priority=5 queue=DL-2048-2048-8;
/queue tree add name=DL-ISP1_2048-2048-8_CLASS-B packet-mark=ISP1_2048-2048-8_CLASS-B_DL parent=DL-ISP1 priority=6 queue=DL-2048-2048-8;
/queue tree add name=UL-ISP1_2048-2048-8_CLASS-A packet-mark=ISP1_2048-2048-8_CLASS-A_UL parent=UL-ISP1 priority=7 queue=UL-2048-2048-8;
/queue tree add name=UL-ISP1_2048-2048-8_CLASS-B packet-mark=ISP1_2048-2048-8_CLASS-B_UL parent=UL-ISP1 priority=8 queue=UL-2048-2048-8;
/queue tree add name=DL-ISP1_1024-1024-7_CLASS-A packet-mark=ISP1_1024-1024-7_CLASS-A_DL parent=DL-ISP1 priority=3 queue=DL-1024-1024-7;
/queue tree add name=DL-ISP1_1024-1024-7_CLASS-B packet-mark=ISP1_1024-1024-7_CLASS-B_DL parent=DL-ISP1 priority=4 queue=DL-1024-1024-7;
/queue tree add name=UL-ISP1_1024-1024-7_CLASS-A packet-mark=ISP1_1024-1024-7_CLASS-A_UL parent=UL-ISP1 priority=5 queue=UL-1024-1024-7;
/queue tree add name=UL-ISP1_1024-1024-7_CLASS-B packet-mark=ISP1_1024-1024-7_CLASS-B_UL parent=UL-ISP1 priority=6 queue=UL-1024-1024-7;
/queue tree add name=DL-ISP1_2048-2048-7_CLASS-A packet-mark=ISP1_2048-2048-7_CLASS-A_DL parent=DL-ISP1 priority=3 queue=DL-2048-2048-7;
/queue tree add name=DL-ISP1_2048-2048-7_CLASS-B packet-mark=ISP1_2048-2048-7_CLASS-B_DL parent=DL-ISP1 priority=4 queue=DL-2048-2048-7;
/queue tree add name=UL-ISP1_2048-2048-7_CLASS-A packet-mark=ISP1_2048-2048-7_CLASS-A_UL parent=UL-ISP1 priority=5 queue=UL-2048-2048-7;
/queue tree add name=UL-ISP1_2048-2048-7_CLASS-B packet-mark=ISP1_2048-2048-7_CLASS-B_UL parent=UL-ISP1 priority=6 queue=UL-2048-2048-7;
/queue tree add name=ISP2-Duplex parent=global queue=default;
/queue tree add name=DL-ISP2 parent=ISP2-Duplex queue=default;
/queue tree add name=UL-ISP2 parent=ISP2-Duplex queue=default;
/queue tree add name=DL-ISP2_1024-1024-8_CLASS-A packet-mark=ISP2_1024-1024-8_CLASS-A_DL parent=DL-ISP2 priority=5 queue=DL-1024-1024-8;
/queue tree add name=DL-ISP2_1024-1024-8_CLASS-B packet-mark=ISP2_1024-1024-8_CLASS-B_DL parent=DL-ISP2 priority=6 queue=DL-1024-1024-8;
/queue tree add name=UL-ISP2_1024-1024-8_CLASS-A packet-mark=ISP2_1024-1024-8_CLASS-A_UL parent=UL-ISP2 priority=7 queue=UL-1024-1024-8;
/queue tree add name=UL-ISP2_1024-1024-8_CLASS-B packet-mark=ISP2_1024-1024-8_CLASS-B_UL parent=UL-ISP2 priority=8 queue=UL-1024-1024-8;
/queue tree add name=DL-ISP2_2048-2048-8_CLASS-A packet-mark=ISP2_2048-2048-8_CLASS-A_DL parent=DL-ISP2 priority=5 queue=DL-2048-2048-8;
/queue tree add name=DL-ISP2_2048-2048-8_CLASS-B packet-mark=ISP2_2048-2048-8_CLASS-B_DL parent=DL-ISP2 priority=6 queue=DL-2048-2048-8;
/queue tree add name=UL-ISP2_2048-2048-8_CLASS-A packet-mark=ISP2_2048-2048-8_CLASS-A_UL parent=UL-ISP2 priority=7 queue=UL-2048-2048-8;
/queue tree add name=UL-ISP2_2048-2048-8_CLASS-B packet-mark=ISP2_2048-2048-8_CLASS-B_UL parent=UL-ISP2 priority=8 queue=UL-2048-2048-8;
/queue tree add name=DL-ISP2_1024-1024-7_CLASS-A packet-mark=ISP2_1024-1024-7_CLASS-A_DL parent=DL-ISP2 priority=3 queue=DL-1024-1024-7;
/queue tree add name=DL-ISP2_1024-1024-7_CLASS-B packet-mark=ISP2_1024-1024-7_CLASS-B_DL parent=DL-ISP2 priority=4 queue=DL-1024-1024-7;
/queue tree add name=UL-ISP2_1024-1024-7_CLASS-A packet-mark=ISP2_1024-1024-7_CLASS-A_UL parent=UL-ISP2 priority=5 queue=UL-1024-1024-7;
/queue tree add name=UL-ISP2_1024-1024-7_CLASS-B packet-mark=ISP2_1024-1024-7_CLASS-B_UL parent=UL-ISP2 priority=6 queue=UL-1024-1024-7;
/queue tree add name=DL-ISP2_2048-2048-7_CLASS-A packet-mark=ISP2_2048-2048-7_CLASS-A_DL parent=DL-ISP2 priority=3 queue=DL-2048-2048-7;
/queue tree add name=DL-ISP2_2048-2048-7_CLASS-B packet-mark=ISP2_2048-2048-7_CLASS-B_DL parent=DL-ISP2 priority=4 queue=DL-2048-2048-7;
/queue tree add name=UL-ISP2_2048-2048-7_CLASS-A packet-mark=ISP2_2048-2048-7_CLASS-A_UL parent=UL-ISP2 priority=5 queue=UL-2048-2048-7;
/queue tree add name=UL-ISP2_2048-2048-7_CLASS-B packet-mark=ISP2_2048-2048-7_CLASS-B_UL parent=UL-ISP2 priority=6 queue=UL-2048-2048-7;
After that, you need to add to the address list “SHAPER_TARGET” subnet ranges with subscribers, make sure that the billing adds the addresses of subscribers to the desired lists, check whether the balancer adds the addresses of subscribers to the channel lists.
You also need to set max-limit values ​​in root queues, these values ​​should be 5-20% lower than the real speed that the provider gives you.
Total:
52 rules in Mangle, 8 profiles, 38 queues.
But if you approach more realistic conditions, you get huge numbers.
Take for example 5 channels and 12 tariff plans.
16 rules in Mangle to determine the types of traffic.
5 channels * 4 rules for sharing = 20 rules in Mangle
5 * (4 * 12 )=240 Mangle
mangle = 276 (260 )
12*2=24
Tree
5 channels for 3 root queues = 15 queues
5 channels * (4 queues for a tariff * 12 tariffs) = 240 queues
Total: 255 queues
And these figures are quite normal to get along with CCR, CHR, X86 if you do not mess with regular expressions. If you want to add another step to determine the type of traffic - multiply the number of queues and rules by two.
For those who, contrary to beliefs, want to fasten the control of internal network segments on the same router to this scheme - multiply the number of rules and queues by the number of segments and add the number of segments multiplied by two to the obtained value.
In this example, with ten segments, the number of rules in mangle will be about 2610, and the number of queues is about 2580.
In addition, if there is inter-subscriber traffic on the network, a rake, which I wrote earlier, will hit the forehead very painfully.
For these purposes, you need a second shaper on the second intermediate router, besides the fact that all this can be relatively simple to implement, the second router still has many useful advantages.
Moreover, the owners of hypervisors raise the second copy is worth nothing.
I think that now many will understand why on SOHO soap dishes with 680 megahertz on board you can only implement a simple seeder for two groups of users and no more.
Well, since I started talking about the second router and about the control of the segments, it’s not a sin to tell you how all this is done.
Distributed sheyper
First of all, you need to mark the traffic on the second router.
Mark external incoming traffic by assigning a label: "EXT_CLASS-B_DL" Next, we catch packets with the label "EXT_CLASS-B_DL" and reassign them by assigning a label of a higher priority class. We do it by analogy as on the first router. After that we received two streams of labeled packets of external incoming traffic: EXT_CLASS-A_DL EXT_CLASS-B_DL Next we need to convert them into four streams, two streams for individuals and two for legal entities , we will do this by remarking according to the address of the tariff plans . Now we have four threads available: EXT_CLASS-A-FL_DL EXT_CLASS-B-FL_DL EXT_CLASS-A-UR_DL EXT_CLASS-B-UR_DL
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B_DL disabled=no src-address-list=!SHAPER_TARGET dst-address-list=SHAPER_TARGET new-packet-mark=EXT_CLASS-B_DL passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-ICMP-DL new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=icmp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-DNS_TCP-DL dst-port=53 new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-DNS_UDP-DL dst-port=53 new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=udp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-SSH-DL dst-port=22 new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-TELNET-DL dst-port=23 new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-RDP-DL dst-port=3389 new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL protocol=tcp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-SITES-DL new-packet-mark=EXT_CLASS-A_DL packet-mark=EXT_CLASS-B_DL src-address-list=CLASS-A-SITES;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-FL_DL new-packet-mark=EXT_CLASS-A-FL_DL packet-mark=EXT_CLASS-A_DL dst-address-list=1024-1024-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-FL_DL new-packet-mark=EXT_CLASS-B-FL_DL packet-mark=EXT_CLASS-B_DL dst-address-list=1024-1024-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-FL_DL new-packet-mark=EXT_CLASS-A-FL_DL packet-mark=EXT_CLASS-A_DL dst-address-list=2048-2048-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-FL_DL new-packet-mark=EXT_CLASS-B-FL_DL packet-mark=EXT_CLASS-B_DL dst-address-list=2048-2048-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-UR_DL new-packet-mark=EXT_CLASS-A-UR_DL packet-mark=EXT_CLASS-A_DL dst-address-list=1024-1024-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-UR_DL new-packet-mark=EXT_CLASS-B-UR_DL packet-mark=EXT_CLASS-B_DL dst-address-list=1024-1024-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-UR_DL new-packet-mark=EXT_CLASS-A-UR_DL packet-mark=EXT_CLASS-A_DL dst-address-list=2048-2048-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-UR_DL new-packet-mark=EXT_CLASS-B-UR_DL packet-mark=EXT_CLASS-B_DL dst-address-list=2048-2048-7;
:
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B_UL disabled=no src-address-list=SHAPER_TARGET dst-address-list=!SHAPER_TARGET new-packet-mark=EXT_CLASS-B_UL passthrough=yes;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-ICMP_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=icmp;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-DNS_TCP_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=tcp src-port=53;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-DNS_UDP_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=udp src-port=53;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-SSH_UP new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=tcp src-port=22;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-TELNET_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=tcp src-port=23;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-RDP_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL protocol=tcp src-port=3389;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-SITES_UL new-packet-mark=EXT_CLASS-A_UL packet-mark=EXT_CLASS-B_UL src-address-list=CLASS-A-SITES;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-FL_UL new-packet-mark=EXT_CLASS-A-FL_UL packet-mark=EXT_CLASS-A_UL src-address-list=1024-1024-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-FL_UL new-packet-mark=EXT_CLASS-B-FL_UL packet-mark=EXT_CLASS-B_UL src-address-list=1024-1024-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-FL_UL new-packet-mark=EXT_CLASS-A-FL_UL packet-mark=EXT_CLASS-A_UL src-address-list=2048-2048-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-FL_UL new-packet-mark=EXT_CLASS-B-FL_UL packet-mark=EXT_CLASS-B_UL src-address-list=2048-2048-8;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-UR_UL new-packet-mark=EXT_CLASS-A-UR_UL packet-mark=EXT_CLASS-A_UL src-address-list=1024-1024-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-UR_UL new-packet-mark=EXT_CLASS-B-UR_UL packet-mark=EXT_CLASS-B_UL src-address-list=1024-1024-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-A-UR_UL new-packet-mark=EXT_CLASS-A-UR_UL packet-mark=EXT_CLASS-A_UL src-address-list=2048-2048-7;
/ip firewall mangle add action=mark-packet chain=forward comment=EXT_CLASS-B-UR_UL new-packet-mark=EXT_CLASS-B-UR_UL packet-mark=EXT_CLASS-B_UL src-address-list=2048-2048-7;
:
EXT_CLASS-A-FL_DL
EXT_CLASS-B-FL_DL
EXT_CLASS-A-UR_DL
EXT_CLASS-B-UR_DL
EXT_CLASS-A-FL_UL
EXT_CLASS-B-FL_UL
EXT_CLASS-A-UR_UL
EXT_CLASS-B-UR_UL
, .. , .
/ip firewall mangle add action=mark-packet chain=forward comment=INT disabled=no src-address-list=SHAPER_TARGET dst-address-list=SHAPER_TARGET new-packet-mark=INT passthrough=yes;
Now we have reached the final stage of labeling. By using partitioned address sheets, we will be able to determine where and from where the packets go. In this example, we have only two segments VID30 and VID40.
Incoming traffic: Outgoing traffic, by analogy: Repeat the same for the second segment: Incoming traffic: Outgoing traffic: This marks the end.
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-A-FL_DL dst-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-A-FL_DL packet-mark=EXT_CLASS-A-FL_DL;
/ip firewall mangle add action=mark-packet chain=forward comment= VID30_EXT_CLASS-B-FL_DL dst-address-list=VID30 new-packet-mark= VID30_EXT_CLASS-B-FL_DL packet-mark=EXT_CLASS-B-FL_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-A-UR_DL dst-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-A-UR_DL packet-mark=EXT_CLASS-A-UR_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-B-UR_DL dst-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-B-UR_DL packet-mark=EXT_CLASS-B-UR_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_INT_DL dst-address-list=VID30 new-packet-mark=VID30_INT_DL packet-mark=INT;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-A-FL_UL src-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-A-FL_UL packet-mark=EXT_CLASS-A-FL_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-B-FL_UL src-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-B-FL_UL packet-mark=EXT_CLASS-B-FL_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-A-UR_UL src-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-A-UR_UL packet-mark=EXT_CLASS-A-UR_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_EXT_CLASS-B-UR_UL src-address-list=VID30 new-packet-mark=VID30_EXT_CLASS-B-UR_UL packet-mark=EXT_CLASS-B-UR_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID30_INT_UL src-address-list=VID30 new-packet-mark=VID30_INT_UL packet-mark=INT;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-A-FL_DL dst-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-A-FL_DL packet-mark=EXT_CLASS-A-FL_DL;
/ip firewall mangle add action=mark-packet chain=forward comment= VID40_EXT_CLASS-B-FL_DL dst-address-list=VID40 new-packet-mark= VID40_EXT_CLASS-B-FL_DL packet-mark=EXT_CLASS-B-FL_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-A-UR_DL dst-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-A-UR_DL packet-mark=EXT_CLASS-A-UR_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-B-UR_DL dst-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-B-UR_DL packet-mark=EXT_CLASS-B-UR_DL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_INT_DL dst-address-list=VID40 new-packet-mark=VID40_INT_DL packet-mark=INT;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-A-FL_UL src-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-A-FL_UL packet-mark=EXT_CLASS-A-FL_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-B-FL_UL src-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-B-FL_UL packet-mark=EXT_CLASS-B-FL_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-A-UR_UL src-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-A-UR_UL packet-mark=EXT_CLASS-A-UR_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_EXT_CLASS-B-UR_UL src-address-list=VID40 new-packet-mark=VID40_EXT_CLASS-B-UR_UL packet-mark=EXT_CLASS-B-UR_UL;
/ip firewall mangle add action=mark-packet chain=forward comment=VID40_INT_UL src-address-list=VID40 new-packet-mark=VID40_INT_UL packet-mark=INT;
Profiles
There is nothing special, two default profiles
/queue type add kind=pcq name=PCQ-DL pcq-classifier=dst-address pcq-dst-address6-mask=64 pcq-rate=0 pcq-src-address6-mask=64;
/queue type add kind=pcq name=PCQ-UL pcq-classifier=src-address pcq-dst-address6-mask=64 pcq-rate=0 pcq-src-address6-mask=64;
Tree
Root queue in which you can set max-limit (connection speed with the first router) Duplex sub-subnet to network segment: Simplex of the segment for download: Queues of descendants: Almost, the same for outgoing traffic: Simplex of the segment for returns: Queues of descendants: Repeat tree for the second segment (VID40) Segment Queue:
/queue tree add name=ISP parent=global queue=default max-limit=900M;
/queue tree add name=DUPLEX-VID30 parent=ISP queue=default max-limit=40M;
/queue tree add name=DL_VID30 parent=DUPLEX-VID30 queue=default;
/queue tree add name=DL_VID30_EXT_CLASS-A-FL_DL packet-mark=VID30_EXT_CLASS-A-FL_DL parent=DL_VID30 priority=5 queue=PCQ-DL;
/queue tree add name=DL_VID30_EXT_CLASS-B-FL_DL packet-mark=VID30_EXT_CLASS-B-FL_DL parent=DL_VID30 priority=6 queue=PCQ-DL;
/queue tree add name=DL_VID30_EXT_CLASS-A-UR_DL packet-mark=VID30_EXT_CLASS-A-UR_DL parent=DL_VID30 priority=4 queue=PCQ-DL;
/queue tree add name=DL_VID30_EXT_CLASS-B-UR_DL packet-mark=VID30_EXT_CLASS-B-UR_DL parent=DL_VID30 priority=5 queue=PCQ-DL;
/queue tree add name=DL_VID30_INT_DL packet-mark=VID30_INT_DL parent=DL_VID30 priority=7 queue=PCQ-DL max-limit=20M;
/queue tree add name=UL_VID30 parent=DUPLEX-VID30 queue=default;
/queue tree add name=UL_VID30_EXT_CLASS-A-FL_UL packet-mark=VID30_EXT_CLASS-A-FL_UL parent=UL_VID30 priority=6 queue=PCQ-UL;
/queue tree add name=UL_VID30_EXT_CLASS-B-FL_UL packet-mark=VID30_EXT_CLASS-B-FL_UL parent=UL_VID30 priority=7 queue=PCQ-UL;
/queue tree add name=UL_VID30_EXT_CLASS-A-UR_UL packet-mark=VID30_EXT_CLASS-A-UR_UL parent=UL_VID30 priority=5 queue=PCQ-UL;
/queue tree add name=UL_VID30_EXT_CLASS-B-UR_UL packet-mark=VID30_EXT_CLASS-B-UR_UL parent=UL_VID30 priority=6 queue=PCQ-UL;
/queue tree add name=UL_VID30_INT_UL packet-mark=VID30_INT_UL parent=UL_VID30 priority=8 queue=PCQ-UL max-limit=20M;
/queue tree add name=DUPLEX-VID40 parent=ISP queue=default max-limit=40M;
Loading:
/queue tree add name=DL_VID40 parent=DUPLEX-VID40 queue=default;
/queue tree add name=DL_VID40_EXT_CLASS-A-FL_DL packet-mark=VID40_EXT_CLASS-A-FL_DL parent=DL_VID40 priority=5 queue=PCQ-DL;
/queue tree add name=DL_VID40_EXT_CLASS-B-FL_DL packet-mark=VID40_EXT_CLASS-B-FL_DL parent=DL_VID40 priority=6 queue=PCQ-DL;
/queue tree add name=DL_VID40_EXT_CLASS-A-UR_DL packet-mark=VID40_EXT_CLASS-A-UR_DL parent=DL_VID40 priority=4 queue=PCQ-DL;
/queue tree add name=DL_VID40_EXT_CLASS-B-UR_DL packet-mark=VID40_EXT_CLASS-B-UR_DL parent=DL_VID40 priority=5 queue=PCQ-DL;
/queue tree add name=DL_VID40_INT_DL packet-mark=VID40_INT_DL parent=DL_VID40 priority=7 queue=PCQ-DL max-limit=20M;
Recoil:
/queue tree add name=UL_VID40 parent=DUPLEX-VID40 queue=default;
/queue tree add name=UL_VID40_EXT_CLASS-A-FL_UL packet-mark=VID40_EXT_CLASS-A-FL_UL parent=UL_VID40 priority=6 queue=PCQ-UL;
/queue tree add name=UL_VID40_EXT_CLASS-B-FL_UL packet-mark=VID40_EXT_CLASS-B-FL_UL parent=UL_VID40 priority=7 queue=PCQ-UL;
/queue tree add name=UL_VID40_EXT_CLASS-A-UR_UL packet-mark=VID40_EXT_CLASS-A-UR_UL parent=UL_VID40 priority=5 queue=PCQ-UL;
/queue tree add name=UL_VID40_EXT_CLASS-B-UR_UL packet-mark=VID40_EXT_CLASS-B-UR_UL parent=UL_VID40 priority=6 queue=PCQ-UL;
/queue tree add name=UL_VID40_INT_UL packet-mark=VID40_INT_UL parent=UL_VID40 priority=8 queue=PCQ-UL max-limit=20M;
That's all.
Naturally, the address list SHAPER_TARGET need to enter all the ranges of the segments, and in the lists of VID30 and VID40 segments of the segments that are on them.
Now I will tell how it works.
Shaper transparently passes all traffic through itself until a limit is reached, which of any of the parent queues. In simple words - while the segment capacity is enough, the shaper does not work, but if a segment has a lot of traffic and exceeds the limit - the speed is cut in accordance with the priorities.
As soon as the limit is reached, the priorities will be processed as follows:
Priority = 4
External traffic of high priority for legal entities is skipped.
Priority = 5
External traffic of low priority is skipped for legal entities. + External traffic of high priority for return for legal entities is skipped. +
External traffic of high priority is ignored for individuals.
Priority = 6
External traffic of low priority is ignored for downloading for individuals +
External traffic of high priority is passed on return for individuals +
External traffic of low priority is passed on for legal entities.
Priority = 7
Inter-subscriber traffic for download + is
skipped + External traffic of low priority for return for individuals is skipped.
Priority = 8
Inter-subscription traffic for return is skipped.
This behavior can be changed by changing the priority of the descendants in the tree, in this case, the priorities are set to "overlap", this allows you to "cram in nevi" in complex configurations, when eight priorities are not enough. In this example, this is only a demonstration of possibilities.
In addition to all priorities, each segment has a forty megabit duplex limit. This is related to the radio and discussed earlier. The exchange of inter-subscriber traffic of 20 megabits per reception and 20 megabits per return per segment is also forcibly limited.
With traffic inside this router, only incoming or outgoing inter-subscriber traffic will be registered.
As I wrote earlier, this rake arises from the fact that the same packet falls under the criteria of two rules, and this behavior cannot be defeated.
Some probably thought: “Inside the segment, the subnet is the same for everyone, they communicate with each other directly (via a base or a switch). How did the packages get into the router?
Internal traffic must be controlled or denied. Broadcast, viruses, scanners and other garbage are very detrimental to the network. If at the base or switch you enable isolation of subscribers, then they will not be able to see each other within this base or switch. But this, however, is not entirely correct and good. The best option is to terminate the individual VLANs on the switch or router. I use the analog ip unnumbered for the implementation of inter-subscriber traffic and control over it.
But this is a completely different topic.
I think it's worth it to finish on this, this wonderful opus.
By tradition, I post the ready-made RSC recent examples for importing into the system, as well as the address sheets for adding Wargaming, Warface and iccup servers to priority. In order to save you from copy-paste during the experiments.
RSC import file with control of channels, prioritization and tariffs (First router)
RSC import file with control of network segments, prioritization and control of inter-subscriber traffic (Second router)
RSC import file with address sheets for adding high priority servers Wargaming, Warface and iccup
PS I will I am glad to hear constructive criticism and comments on the data in the examples of designs. I will also be glad to communicate and exchange experience with experienced people in this field. My contacts you can find in the profile.
Thanks for attention!
Source: https://habr.com/ru/post/307214/
All Articles