Linux Controls Network QoS via TC (1) __linux

TC is the abbreviation of Linux traffic control, the principle is that when the protocol stack out of the packet, through the Qdisc (Queue discipline) and filter mechanism to the different rules of the definition of the exile to the different class Qdisc (for classful Qdisc is so, for classless Qdisc only one root qdisc). There are a lot of data on TC on the Internet, this article does not discuss the use of various Qdisc, class, filter or different classful/classless class of TC, but only do some research for Htb+iptables/ebtables way.

HTB is an implementation of classful Qdisc, Latrc.org recommends using HTB as CBQ classful configuration, in Qdisc, there are many ways to distinguish different streams, such as HTB u32. Let's take a look at Lartc.org's famous document Linux Advanced Routing&traffic control howto Example

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

#tc class Add dev eth0 parent 1:classid 1:10 HTB rate 5mbit Burst 15k

#tc class Add dev eth0 parent 1:classid 1:20 HTB rate 3mbit ceil 5mbit burst 15k

#tc class Add dev eth0 parent 1:classid 1:30 HTB rate 500kbit ceil 1mbit burst 15k

#tc Qdisc Add dev eth0 parent 1:10 handle 10:SFQ perturb 10

#tc Qdisc Add dev eth0 parent 1:20 handle 20:SFQ perturb 10

#tc Qdisc Add dev eth0 parent 1:30 handle 30:SFQ perturb 10

The scenario for this example is to divide the flow of eth0 into three categories, limiting rate, ceil bandwidth, and burst traffic (the meaning of specific values refer to HTB related documents, where 1:30 is the default), and for each class of traffic, a SFQ child qdisc is used to ensure fairness. The reason for this, for example, is that a lot of process traffic can match to ClassID 1:10, which is the common bandwidth of these processes, through a SFQ to ensure that no process bandwidth is starved to death.

Finally this example through a u32 selector to distinguish traffic, you can see that HTTP traffic is divided into class 1:10,SMTP traffic is divided into class 1:20, the rest in the default class 1:30, all processes sharing HTTP traffic are shared in a fair manner

We can match different streams in u32 match, and here's no nonsense, and interested in looking at the document mentioned above. Personally think that u32 match can match different protocols such as IP TCP ICMP, and match such as IP segment, port, etc., but after all, not as iptables more flexible, while u32 match for two layers of sense, which all make it through iptables/ebtables Mark aims to make the filter more flexible and controllable.

For two examples, the first is TC + iptables to the IP address 192.168.1.1 packet to do QoS, limit bps to 2Mbit, allow burst bps up to 5Mbit

#tc qdisc add dev eth0 root handle 1:htb default 100

#tc class Add dev eth0 parent 1:classid 1:10 HTB rate 2Mbit ceil 5Mbit

#iptables-T mangle-a postrouting-s 192.168.1.1-j classify--set-class 1:10

TC + iptables Only three layer of traffic to do QoS, if it is two levels of traffic, only through TC + Ebtables, the following example to limit the ARP message bps

#tc qdisc add dev eth0 root handle 1:htb default 100

#tc class Add dev eth0 parent 1:classid 1:20 HTB rate 1Kbit ceil 5Kbit

#tc filter Add dev eth0 prio protocol ARP handle 127 FW ClassID 1:10

TC also can be in the packet for QoS, this time if the packet flow to the filter, only rely on U32 match this module

#tc qdisc Add Dev vif8.0 ingress

#tc filter Add dev vif8.0 parent ffff:protocol IP prio u32 match IP src 0.0.0.0/0 Police rate 100bps burst 1k drop CLA SSID 16

Ingress's classid are always FFFF, so each time you add a filter, its parent is FFFF:

Protocol can be IP or ARP, if the following byte for U32 match, here protocol in fact nothing to use

Prio represents priority, this value must be set

Since protocol is set up with IP, you can use IP src, IP DST, and so on to set the filter rule for parameters such as TCP port. IP src 0.0.0.0/0 indicates matching any IP

Police rate 100bps burst 1k drop, represents a flow control strategy, rate 100bps represents Bytes per Second,burst is a buffer value, allowing temporary over rate packet traffic, Drop means more than stream-controlled packet drop

ClassID can also be flowid, which indicates the identity of a filter, which must be set

If you want to match all the ARP packets,

#tc filter Add dev vif8.0 parent ffff:protocol arp prio u32 match IP src 0.0.0.0/0 Police rate 100bps burst 1k Drop cl Assid:16

Set the protocol directly to ARP, the IP src behind is actually ignored

Or

#tc filter Add dev vif8.0 parent ffff:protocol IP prio u32 match U16 0x0806 0xFFFF at-2 Police rate 100bps Burst 1k D ROP Classid:16

Matches 4 bytes of the protocol header through U32 match. The position here is 0 points to the IP packet's payload, so the protocol header is a total of four bytes from 2 to 0 of the two U16 added.

We can also match MAC addresses with u32 match.

#tc filter Add dev vif8.0 parent ffff:protocol arp prio u32 match U16 0x0001 0xFFFF at-4 match u32 0x00163e00 0xFFFFF FFF at-8 Police rate 100bps burst down classid:16

At this point only the source MAC for 00:16:3e:00:00:01 ARP packet will match

The removal of TC rules is as follows

#tc filter del Dev vif8.0 parent ffff:pref 64

#tc qdisc del Dev vif8.0 Ingress

There's also a simpler way to flush a device's TC rule, which is to call

TC Qdisc del Dev xxxx root