Introduction to Linux TC (traffic control) (i) __linux

As we all know, in the beginning of the Internet are all universities and scientific research institutions to 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, the different data flow is equal. However, years of practice have shown that this principle is not ideal, some data streams should be given special care, for example, remote logins of the interactive data stream should be higher than the data download priority.

This possibility exists for different strategies to be 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 issued several standards, such as Integrated Services (integrated service), Differentiated Services (diferentiated service), and so on. In fact, the Linux kernel starts from 2.2, has already realized the related flow control function. This article will introduce the relevant concepts of traffic control in Linux, use the tool TC for flow control, and give several representative examples. I. Related Concepts

Packet packets from the input network card (portal) received, through the routing of the lookup, to determine whether it is sent to the machine, or need to forward. If it is sent to the local, directly forward to the upper level of the protocol, such as TCP, if it is forwarded, will be issued from the Output network card (export). The control of network traffic usually occurs at the output NIC. Although at the entrance of the router can also carry out traffic control, Linux also has related functions, but generally speaking, because we can not control the equipment outside our own network, the entrance of the flow control is relatively difficult. So the flow control we deal with here generally refers to the flow control at the exit. A basic concept of flow control is the queue (QDISC), each NIC is associated with a queue (QDISC), and whenever the kernel needs to send packets out of the NIC, the packet is first added to the queue configured by the NIC, which determines the order in which packets are 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 Message in Linux internal flowchart

The functions of some queues are very simple, and they implement the first-go strategy for packet packets. Some queues have complex functions, queue and classify different packets, 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 packets into different categories (class). These complex queues are called categorized (classiful) queues here. In general, to achieve powerful traffic control, a categorized queue is essential. Therefore, class (class) and filter (filter) are two other important basic concepts of flow control. Figure 2 shows an example of a categorized queue.

Figure 2 Multi-category queues

As you can see from Figure 2, Categories (Class) and filters (filter) are the internal structure of the queue, and the categorized queues can contain multiple categories, while a category can further contain child queues, or subcategories. All packets entering the class can be grouped into different sub queues or subcategories according to different principles, and so on. Filters (filter) are tools used by queues to classify data messages, which determines which categories a datagram will be assigned to. second, the use of TC

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

Configure a queue for the NIC;

The classification is established on the queue;

establish sub queues and subcategories according to the need;

Create filters for each category.

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

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

Below, will take the HTB queue primarily, unifies the demand to describe the TC the use. Suppose eth0 export has 100mbit/s bandwidth, allocated to WWW, e-mail and Telnet Three kinds of data traffic, which allocated to the WWW bandwidth of 40mbit/s, allocated to the bandwidth of the email is 40mbit/s, allocated to Telnet bandwidth of 20Mbit S

It should be noted that the following abbreviations are used in TC to represent the appropriate bandwidth:

Kbps:kilobytes per second, thousand bytes/sec;

Mbps:megabytes per second, megabytes/sec,

Kbit:kilobits per second, thousand bits/second;

Mbit:megabits per second, megabyte/sec. third, create HTB queues

The general form of TC commands for queues 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 the NIC to operate is eth0. "Root" is a root queue that is added to the NIC Eth0. "Handle 1:" Indicates that the queue's handle is 1:. "HTB" indicates that the queue to be added is a HTB queue. The final "default 11" of the command is a HTB-specific queue parameter, meaning that all unclassified traffic is assigned to category 1:11. create the appropriate category for the root queue

The general form of TC commands for categories is:

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

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

#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:" Indicates that the father of the category is the root queue 1:. "Classid1:11" means to create a category that is identified as 1:11, "rate 40mbit" means that the system will ensure bandwidth 40mbit for this category, "Ceil 40mbit", which indicates that the maximum available bandwidth for this category is 40mbit. v. Set up 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 allocate WWW, e-mail, telnet three traffic to three categories, that is, 1:11, 1:12, and 1:13, 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, "Protocol IP" means that the filter should check the protocol fields for packet packets. "Prio 1" means that they have the same priority for message processing, and for different priority filters, the system will execute the filter in the order of priority from small to large, and for the same priority, the system will be executed in the order of precedence. 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 "Flowid 1:11" indicates that the data flow will be assigned to category 1:1 1 if the result of the field and Oxffff is 8O. More detailed usage of TC can refer to the manual page of the TC. Vi. Complex Examples

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

First you need to use one of the attributes of HTB, that is, for all subcategories in a category, they will share the bandwidth that the parent class has, while at the same time make sure that the respective bandwidth of each subcategory request is guaranteed. This means that when the actual bandwidth of a data stream does not reach its quota, its remaining bandwidth can be lent to other data streams. In the process of loan, if the data volume of this data stream increases, the bandwidth portion of the loan will be retracted to guarantee the bandwidth quota of this data stream.

The following considerations for this requirement are 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 Figure 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 a telnet stream, and 1:2 corresponds to a 80Mbit data stream. Then, in 1:2, create two subcategories 1:21 and 1:22, which correspond to the WWW and e-mail data streams respectively. Because categories 1:21 and 1:22 are subcategories of category 1:2, they can share allocated 80Mbit of bandwidth. At the same time, make sure that your bandwidth is at least 40Mbit when you need it.

It can be seen from this example that the use of the inclusion relationship of categories and subcategories in HTB can build more complex hierarchical tree types to achieve more flexible bandwidth sharing and exclusive mode to achieve enterprise-wide bandwidth management purposes.
Original link: http://m.blog.csdn.net/blog/zhaobryant/38797655