Introduction to Linux TC (traffic Control)

As we all know, at the beginning of the birth of the Internet are all universities and scientific research institutions communicate with each other, and there is no network traffic control considerations and design, the principle of IP protocol is as good as possible for all data flow services, different data flow is equal. However, years of practice have shown that this principle is not ideal, and some data streams should be given special care, for example, the interactive data stream of Telnet should have higher priority than the data download.

This possibility exists when different strategies are adopted for different data streams. And, with the development and deepening of research, people have put forward a variety of different management models. The IETF has published several standards, such as Integrated Services (Integrated service), Differentiated Services (diferentiated service), and so on. In fact, the Linux kernel, starting from 2.2, has implemented the relevant traffic control functions. This paper introduces the related concepts of traffic control in Linux, uses the tool TC for flow control, and gives several representative examples.

first, related concepts

packet packets are received from the input network card (ingress), routed through the lookup to determine whether it is sent to the local, or need to be forwarded. If it is sent to the local, it is directly up to the upper layer of the Protocol, such as TCP, if it is forwarded, it will be sent from the output network card (egress). The control of network traffic usually occurs at the output network card. Although traffic can be controlled at the entrance of the router, Linux also has related functions, but generally speaking, the traffic control at the entrance is relatively difficult because we cannot control the devices outside of our network. So the flow control we handle here generally refers to the flow control at the outlet. A basic concept of flow control is the queue (QDISC), each network card is associated with a queue (QDISC), each time the kernel needs to send packets from the network card, the packet is first added to the queue configured by the network card, the queue determines the order in which the packet is sent. So it can be said that all traffic control occurs in the queue, the detailed flow chart is shown in Figure 1.

Figure 1 Internal flowchart of the message in Linux

The functions of some queues are very simple, and they implement a first-come-first-go strategy for packet grouping. Some queues are complex and can queue up different packets, classify them, and send packets in different order according to different principles. To achieve such a function, these complex queues need to use different filters (filter) to group the packets into different classes (class). These complex queues are referred to as classiful queues. In general, a categorized queue is essential for powerful traffic control. Therefore, the categories (class) and filters (filter) are also two other important basic concepts of flow control. Figure 2 shows an example of a class that can be categorized as a queue.

Figure 2 Multi-category queue

as can be seen from Figure 2, the class and filter (filter) are the internal structure of the queue, and the categorized queue can contain multiple categories, while a category can further contain sub-queues, or subcategories. All packet groupings that enter the class can be placed in different sub-queues or subcategories according to different principles, and so on. A filter is a tool that the queue uses to classify data messages, which determines which category a data message will be assigned to.

second, the use of TC

in Linux, the flow control is done through the TC tool. In general, to configure the network card for flow control, the following steps are required:

Configure a queue for the network card;

The classification is established on the queue;

Sub-queues and sub-classifications are established as needed;

Create filters for each category.

in Linux, you can configure many types of queues, such as CBQ, HTB, and so on, where CBQ is more complex and difficult to understand. The HTB (Hierarchical Token Bucket) is a categorized queue that, compared to other complex queue types, has the advantages of being powerful, simple to configure, and easy to get started with HTB. In TC, a handle such as "Major:minor" is used to identify queues and categories , where both major and minor are numbers.

for a queue, minor is always 0, or "major:0", or "major:" For example, queue 1:0 can be shortened to 1:. It is important to note that the major must be unique across all the queues in a network card. For a category, its major must be the same as its parent class or parent queue, and minor must be unique within a queue (because the category must be contained in a queue). For example, if queue 2: contains two categories, the handles of these two categories must be in the form of 2:x, and their x cannot be the same, such as 2:1 and 2:2.

below, the HTB queue will be the main, combined with requirements to tell the use of TC. Assuming that the eth0 outlet has 100mbit/s bandwidth, assigned to WWW, e-mail and Telnet three data traffic, which is allocated to the WWW bandwidth of 40mbit/s, the bandwidth allocated to the email is 40mbit/s, the bandwidth allocated to Telnet is 20Mbit S

It is important to note that the following abbreviations are used in the TC to indicate the appropriate bandwidth:

kbps:kilobytes per second, Kbytes/second;

mbps:megabytes per second, MBytes per second,

kbit:kilobits per second, thousand bits/second;

mbit:megabits per second, Mbit/s.

Third, create HTB queue

The general form of the TC command for the queue is:

#tc Qdisc [Add | change | replace | link] Dev dev [parent qdisk-id |root] [handle Qdisc-id] Qdisc [Qdisc specific Paramete Rs

First, you need to configure a HTB queue for the NIC Eth0, using the following command:

#tc qdisc add dev eth0 root handle 1:HTB default 11

here, "add" in the command means to add, "dev eth0" means that the NIC to be operated on is eth0. "Root" means that a root queue is added for the NIC Eth0. "Handle 1:" indicates that the handle of the queue is 1:. "HTB" indicates that the queue to be added is a HTB queue. The last "default 11" of the command is the HTB-specific queue parameter, meaning that all unclassified traffic is assigned to category 1:11.

Iv. Create the appropriate category for the root queue

The general form of the TC command for the category is:

#tc class [Add | change | replace] Dev dev parent qdisc-id [classid Class-id] qdisc [qdisc specific parameters]

You can use these three commands to create three categories for root queue 1, 1:1 1, 1:12, and 1:13, respectively, that occupy 40, 40, and 20mb[t of bandwidth.

#tc class add dev eth0 parent 1:classid 1:1 HTB rate 40mbit ceil 40mbit

#tc class add dev eth0 parent 1:classid 1:12 HTB rate 40mbit ceil 40mbit

#tc class add dev eth0 parent 1:cllassid 1:13 HTB rate 20mbit ceil 20mbit

Command, "Parent 1:" Represents the father of the category for root queue 1:. "Classid1:11" means creating a category that is identified as 1:11, and "rate 40mbit" means that the system will ensure bandwidth 40mbit, "Ceil 40mbit" for that category, indicating that the class can occupy a maximum bandwidth of 40mbit.

Five. Set filters for each category

The general form of the TC command for the filter is:

#tc Filter [Add | change | replace] Dev dev [parent Qdisc-id | root] Protocol protocol Prio Priority FilterType [Filtertyp E specific parameters] Flowid Flow-id

because of the need to assign WWW, e-mail, telnet three traffic to three categories, namely 1:11, 1:12 and 1:13 above, you need to create three filters, such as the following three commands:

#tc Filter Add dev eth0 protocol IP parent 1:0 prio 1 u32 match IP dport 0xffff flowid 1:11

#tc filter Add dev eth0 prtocol IP parent 1:0 prio 1 u32 match IP dport 0xffff flowid 1:12

#tc Filter Add dev eth0 protocol IP parent 1:0 prio 1 u32 match IP dport oxffff flowid 1:13

here, the "Protocol IP" indicates that the filter should check the Protocol field of the packet packet. "Prio 1" means that they have the same priority for message processing, and for different priority filters, the system executes the filter in order of priority from small to large, and the system executes in order of precedence for the same priority. These filters also use the U32 selector (the part behind the u32 in the command) to match the different data streams. Taking the first command as an example, the Dport field is judged, and if the field is 8O with Oxffff, then "Flowid 1:11" means that the data stream will be assigned to category 1:1 1. More detailed information on the use of TC can be found in the TC manual page.

vi. Examples of complexity

In the example above, three data streams (WWW, Email, Telnet) are mutually exclusive. When the traffic for a stream does not reach the quota, its remaining bandwidth cannot be borrowed by the other two data streams. Here will be how to make different traffic can share a certain amount of bandwidth.

One of the features of HTB is that for all subcategories in a category, they will share the bandwidth owned by that parent class, while at the same time allowing the respective bandwidth for each subcategory to be guaranteed. This means that when the actual usage bandwidth of a data stream does not reach its quota, its remaining bandwidth can be lent to other traffic. In the process of borrowing, if the amount of data in this data stream increases, the portion of the borrowed bandwidth is retracted to guarantee the bandwidth quota of this traffic.

Consider the requirement below, which is also three data streams www, e-mail, and Telnet, where Telnet allocates 20mbit/s bandwidth independently. On the other hand, WWW and SMTP each allocate 40mbit/s bandwidth. At the same time, they are shared relationships, that is, they can borrow bandwidth from each other. As shown in 3.

the required TC commands are as follows:

#tc qdisc add dev eth0 root handle 1:HTB default 21

#tc class add dev eth0 partent 1:classid 1:1 HTB rate 20mbit ceil 20mbit

#tc class add dev eth0 parent 1:classid 1:2 HTB rate 80mbit ceil 80mbit

#tc class add dev eth0 parent 1:classid 1:21 HTB rate 40mbit ceil 20mbit

#tc class add dev eth0 parent 1:2 classid 1:22 HTB rate 40mbit ceil 80mbit

#tc Filter Add dev eth0 protocol parent prio 1 u32 match IP dport 0xffff flowid 1:21

#tc Filter Add dev eth0 protocol parent 1:0 prio 1 u32 match IP dport 0xffff flowid 1:22

#tc Filter Add dev eth0 protocol parent 1:0 prio 1 u32 match IP dport 0xffff flowid 1:1

This creates two root categories for root queue 1, 1:1 and 1:2, where 1:1 corresponds to the Telnet traffic and 1:2 corresponds to the 80Mbit data stream. Then, in 1:2, create two subcategories 1:21 and 1:22, respectively, corresponding to the WWW and e-mail data streams. Because categories 1:21 and 1:22 are subcategories of category 1:2, they can share the allocated 80Mbit bandwidth. At the same time, make sure that your bandwidth is at least 40Mbit when you need it.

From This example, it can be seen that the inclusion relationships of categories and subcategories in HTB can be used to build more complex multi-layered category trees to achieve more flexible bandwidth sharing and exclusive mode for enterprise-level bandwidth management purposes.

Introduction to Linux TC (traffic Control)